Re: type error formatting
I have the same issue with the current error messages. I think these are all good ideas. On 10/24/2015 05:48 AM, Evan Laforge wrote: > Here's a typical simple type error from GHC: > > Derive/Call/India/Pakhawaj.hs:142:62: > Couldn't match type ‘Text’ with ‘(a1, Syllable)’ > Expected type: [([(a1, Syllable)], [Sequence Bol])] > Actual type: [([Syllable], [Sequence Bol])] > Relevant bindings include > syllables :: [(a1, Syllable)] > (bound at Derive/Call/India/Pakhawaj.hs:141:16) > best_match :: [(a1, Syllable)] > -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) > (bound at Derive/Call/India/Pakhawaj.hs:141:5) > In the second argument of ‘mapMaybe’, namely ‘all_bols’ > In the second argument of ‘($)’, namely > ‘mapMaybe (match_bols syllables) all_bols’ > > I've been having more trouble than usual reading GHC's errors, and I > finally spent some time to think about it. The problem is that this new > "relevant bindings include" section gets in between the expected and > actual types (I still don't like that wording but I've gotten used to > it), which is the most critical part, and the location context, which is > second most critical. Notice the same effect in the previous sentence > :) After I see a type error the next thing I want to see is the where > it happened, so I have to skip over the bindings, which can be long and > complicated. Then I usually know what to do, and only look into the > bindings if something more complicated is going on, like wonky > inference. So how about reordering the message: > > Derive/Call/India/Pakhawaj.hs:142:62: > Couldn't match type ‘Text’ with ‘(a1, Syllable)’ > Expected type: [([(a1, Syllable)], [Sequence Bol])] > Actual type: [([Syllable], [Sequence Bol])] > In the second argument of ‘mapMaybe’, namely ‘all_bols’ > In the second argument of ‘($)’, namely > ‘mapMaybe (match_bols syllables) all_bols’ > Relevant bindings include > syllables :: [(a1, Syllable)] > (bound at Derive/Call/India/Pakhawaj.hs:141:16) > best_match :: [(a1, Syllable)] > -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) > (bound at Derive/Call/India/Pakhawaj.hs:141:5) > > After this, why not go one step further and set off the various sections > visibly to make it easier to scan. The context section can also be > really long if it gets an entire do block or record: > > Derive/Call/India/Pakhawaj.hs:142:62: > * Couldn't match type ‘Text’ with ‘(a1, Syllable)’ > Expected type: [([(a1, Syllable)], [Sequence Bol])] > Actual type: [([Syllable], [Sequence Bol])] > * In the second argument of ‘mapMaybe’, namely ‘all_bols’ > In the second argument of ‘($)’, namely > ‘mapMaybe (match_bols syllables) all_bols’ > * Relevant bindings include > syllables :: [(a1, Syllable)] > (bound at Derive/Call/India/Pakhawaj.hs:141:16) > best_match :: [(a1, Syllable)] > -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) > (bound at Derive/Call/India/Pakhawaj.hs:141:5) > > Or alternately, taking up a bit more vertical space: > > Derive/Call/India/Pakhawaj.hs:142:62: > Couldn't match type ‘Text’ with ‘(a1, Syllable)’ > Expected type: [([(a1, Syllable)], [Sequence Bol])] > Actual type: [([Syllable], [Sequence Bol])] > - > In the second argument of ‘mapMaybe’, namely ‘all_bols’ > In the second argument of ‘($)’, namely > ‘mapMaybe (match_bols syllables) all_bols’ > - > Relevant bindings include > syllables :: [(a1, Syllable)] > (bound at Derive/Call/India/Pakhawaj.hs:141:16) > best_match :: [(a1, Syllable)] > -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) > (bound at Derive/Call/India/Pakhawaj.hs:141:5) > > Thoughts? It seems simple enough that I could do myself, but of course > not without buy-in. signature.asc Description: OpenPGP digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Functional dependencies conflict
On 05/04/15 15:54, Daniel Trstenjak wrote: On Sun, Apr 05, 2015 at 03:25:01PM +0300, Roman Cheplyaka wrote: Data.ByteString.Lazy.Char8 exports the same lazy bytestring type as Data.ByteString.Lazy. Only functions and instances differ. So my only option in this case is to define a newtype wrapper for Data.ByteString.Lazy and then define a Stream instance on this one? You might do that. But if I were you, I'd use attoparsec or even binary/cereal to parse PNG. They are better suited for parsing binary data. Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Functional dependencies conflict
To be precise, the sets of instances differ. Eg. the Char8 module
exports the IsString instance, which normal Data.ByteString.Lazy doesn't.
On 05/04/15 15:25, Ivan Lazar Miljenovic wrote:
On 5 April 2015 at 22:25, Roman Cheplyaka r...@ro-che.info wrote:
Data.ByteString.Lazy.Char8 exports the same lazy bytestring type as
Data.ByteString.Lazy. Only functions and instances differ.
Well, *instances* can't differ...
On 05/04/15 15:19, Daniel Trstenjak wrote:
Hi,
I'm getting the compile error:
Gamgine/Image/PNG/Internal/Parser.hs:14:10:
Functional dependencies conflict between instance declarations:
instance Monad m = Stream LB.ByteString m Word8
-- Defined at Gamgine/Image/PNG/Internal/Parser.hs:14:10
instance Monad m = Stream LB.ByteString m Char
-- Defined in ‘Text.Parsec.Prim’
The relevant stuff from the parsec 3.1.9 code[1] is:
{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies,
FlexibleContexts, UndecidableInstances #-}
...
import qualified Data.ByteString.Lazy.Char8 as CL
import qualified Data.ByteString.Char8 as C
...
class (Monad m) = Stream s m t | s - t where
uncons :: s - m (Maybe (t,s))
instance (Monad m) = Stream CL.ByteString m Char where
uncons = return . CL.uncons
instance (Monad m) = Stream C.ByteString m Char where
uncons = return . C.uncons
And from my code[2] is:
{-# LANGUAGE BangPatterns, FlexibleInstances, MultiParamTypeClasses,
FlexibleContexts #-}
...
import qualified Data.ByteString.Lazy as LB
...
instance (Monad m) = Stream LB.ByteString m Word8 where
uncons = return . LB.uncons
As you can see, the instances are for different ByteString types,
therefore I don't quite get where GHC sees here any conflicts.
Greetings,
Daniel
[1] https://github.com/aslatter/parsec/blob/master/Text/Parsec/Prim.hs
[2]
https://github.com/dan-t/Gamgine/blob/master/Gamgine/Image/PNG/Internal/Parser.hs
___
Haskell-Cafe mailing list
haskell-c...@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
haskell-c...@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Functional dependencies conflict
Data.ByteString.Lazy.Char8 exports the same lazy bytestring type as
Data.ByteString.Lazy. Only functions and instances differ.
On 05/04/15 15:19, Daniel Trstenjak wrote:
Hi,
I'm getting the compile error:
Gamgine/Image/PNG/Internal/Parser.hs:14:10:
Functional dependencies conflict between instance declarations:
instance Monad m = Stream LB.ByteString m Word8
-- Defined at Gamgine/Image/PNG/Internal/Parser.hs:14:10
instance Monad m = Stream LB.ByteString m Char
-- Defined in ‘Text.Parsec.Prim’
The relevant stuff from the parsec 3.1.9 code[1] is:
{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, FlexibleContexts,
UndecidableInstances #-}
...
import qualified Data.ByteString.Lazy.Char8 as CL
import qualified Data.ByteString.Char8 as C
...
class (Monad m) = Stream s m t | s - t where
uncons :: s - m (Maybe (t,s))
instance (Monad m) = Stream CL.ByteString m Char where
uncons = return . CL.uncons
instance (Monad m) = Stream C.ByteString m Char where
uncons = return . C.uncons
And from my code[2] is:
{-# LANGUAGE BangPatterns, FlexibleInstances, MultiParamTypeClasses,
FlexibleContexts #-}
...
import qualified Data.ByteString.Lazy as LB
...
instance (Monad m) = Stream LB.ByteString m Word8 where
uncons = return . LB.uncons
As you can see, the instances are for different ByteString types,
therefore I don't quite get where GHC sees here any conflicts.
Greetings,
Daniel
[1] https://github.com/aslatter/parsec/blob/master/Text/Parsec/Prim.hs
[2]
https://github.com/dan-t/Gamgine/blob/master/Gamgine/Image/PNG/Internal/Parser.hs
___
Haskell-Cafe mailing list
haskell-c...@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Binary bloat in 7.10
On 01/04/15 12:30, Jeremy wrote: Why do the 7.10 libraries take up so much more space than 7.8? For example, using the same build options and strip --strip-unneeded, 7.8 leaves me with 15M libHSCabal-1.18.1.5.a 17M HSCabal-1.18.1.5.o whereas 7.10 balloons to 23M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o 53M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a I'm not denying (or confirming) your claim, but it would look more legitimate if you compared the same version of Cabal compiled with different versions of GHC. At least some of this bloat could be because Cabal simply gained more code. Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Proposal: Turn on ScopedTypeVariables by default
On 24/02/15 14:46, Herbert Valerio Riedel wrote: On 2015-02-23 at 18:45:20 +0100, David Feuer wrote: I know this will be controversial, because it can break (weird) code and because it's not Haskell 2010, but hey, you can't make brain salad without breaking a few heads. Are you suggesting enabling -XScopedTypeVariables for -XHaskell98 and -XHaskell2010? or rather for the default when neither of those two modes is explicitly requested? Just be warned though: this is somewhat of a trick-question... :-) Maybe in addition to -XHaskell98 and -XHaskell2010 there should also be -XGhcHaskell. ghc already deviates from the standard by default (e.g. -XNondecreasingIndentation). OTOH we probably don't want end up with -fglasgow-exts once again. Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/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
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
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
Re: Discovery of source dependencies without --make
On 25/11/14 12:29, Joachim Breitner wrote:
Dear Lars,
Am Dienstag, den 25.11.2014, 10:36 +0100 schrieb Lars Hupel:
The invocation is similar to this:
ghc -c -outputdir $OUT -XTrustworthy Library.hs
ghc -c -outputdir $OUT -i$OUT -XSafe $SUBMISSION
ghc -c -outputdir $OUT -i$OUT Test_Suite.hs
ghc-outputdir $OUT -i$OUT -o $OUT/runner
the only reason you do these in individual steps is that you need to
pass different flags, or are there other reasons?
Have you tried putting the pragma {-# LANGUAGE Safe #-} as the first
line into the submission file? I’m not sure how safe that actually is,
but at least
{-# LANGUAGE Safe #-}
{-# LANGUAGE Trustworthy #-}
module Foo where
import Unsafe.Coerce
is rejected by 7.6.3. This way, it could work with a single invocation
of --make.
The only problem I see with that is that error message locations will be
a bit off, since the file being compiled is different from the file
submitted. But since we're in the hacks territory anyway, this could be
fixed up with a simple regex :-)
Roman
signature.asc
Description: OpenPGP digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
* Simon Marlow marlo...@gmail.com [2014-04-28 09:26:23+0100] On 25/04/2014 17:57, Roman Cheplyaka wrote: * Edward Kmett ekm...@gmail.com [2014-04-25 11:22:46-0400] +1 from me. I have a lot of projects that suffer with 4 levels of vacuous subdirectories just for this. In theory cabal could support this on older GHC versions by copying all of the files to a working dir in dist with the expected layout on older GHCs. That would enable this to get much greater penetration more quickly. I'd really not want that people start putting ghc-options: -isrc=... into their cabal files. That'd make them irrecoverably ghc-specific, as no other tool will know how to process the files unless it reads ghc-options. No, the idea would be to use hs-source-dirs like this: hs-source-dirs: A.B.C=src Cabal just passes this in a -i option to GHC, so it almost Just Works, except that Cabal needs to preprocess some source files so it needs to find them, and also sdist needs to find source files. In that case, I'm in favour of this proposal. Please consider the reversed syntax instead: hs-source-dirs: src=A.B.C I find it more intuitive, because A.B.C becomes sort of an optional parameter, the empty prefix being its default value. Roman signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
* Felipe Lessa felipe.le...@gmail.com [2014-04-25 13:01:43-0300] Em 25-04-2014 12:22, Edward Kmett escreveu: +1 from me. I have a lot of projects that suffer with 4 levels of vacuous subdirectories just for this. In theory cabal could support this on older GHC versions by copying all of the files to a working dir in dist with the expected layout on older GHCs. That would enable this to get much greater penetration more quickly. What if you had a real-src directory with all your files as they are now, and a src symlink pointing inside your directory tree? I don't think Windows users can enjoy this, but it's a neat idea. Roman signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
* Edward Kmett ekm...@gmail.com [2014-04-25 11:22:46-0400] +1 from me. I have a lot of projects that suffer with 4 levels of vacuous subdirectories just for this. In theory cabal could support this on older GHC versions by copying all of the files to a working dir in dist with the expected layout on older GHCs. That would enable this to get much greater penetration more quickly. I'd really not want that people start putting ghc-options: -isrc=... into their cabal files. That'd make them irrecoverably ghc-specific, as no other tool will know how to process the files unless it reads ghc-options. I'm +1 on adding support for this to cabal. Then the mechanism cabal uses to achieve this is just that — an implementation detail. And this new -i syntax can become one of such mechanisms. But cabal support should really come first, so that people aren't tempted by ghc-specific solutions. Roman signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: HSghc-prim-0.3.1.0.o: unknown symbol 'memcpy'
* M Farkas-Dyck strake...@gmail.com [2014-04-19 12:18:31-0500] I just built stock ghc 7.8.1 against musl on Linux x86_64. I get this: $ ghci GHCi, version 7.8.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... ghc: /lib/ghc-7.8.1/ghc-prim-0.3.1.0/HSghc-prim-0.3.1.0.o: unknown symbol `memcpy' ghc: unable to load package `ghc-prim' $ memcpy is defined in /lib/libc.a; how can I link it in? I tried -lc and -opt-lc options to ghci, in vain. Don't know if it helps, but I think ghci loads the dynamic library, not the static one. Roman signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: HSghc-prim-0.3.1.0.o: unknown symbol 'memcpy'
* M Farkas-Dyck strake...@gmail.com [2014-04-19 12:55:23-0500] On 19/04/2014, Roman Cheplyaka r...@ro-che.info wrote: Don't know if it helps, but I think ghci loads the dynamic library, not the static one. I straced both the broken ghci on aforesaid system and a working ghci on a glibc system and it loads bare .o files. Interesting. I thought that has changed in 7.8. I'd love to see an explanation from someone knowledgeable. Roman signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposal - Foreign enum support
I am reluctant about adding a new syntactic feature for such a niche problem. Can't this be achieved with a quaiquoter? Roman signature.asc Description: Digital signature ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Solaris bindist] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
* Christian Maeder christian.mae...@dfki.de [2014-02-05 16:28:50+0100] This happens, because our /bin/sh is a real sh (and not a bash) that only allows to export LD_LIBRARY_PATH as a separate command. You mean it's a real sh and not a POSIX-compatible one. http://pubs.opengroup.org/onlinepubs/009695399/utilities/export.html Roman signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Solaris bindist] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
* Brandon Allbery allber...@gmail.com [2014-02-05 11:06:04-0500] On Wed, Feb 5, 2014 at 11:02 AM, Christian Maeder christian.mae...@dfki.dewrote: Am 05.02.2014 16:45, schrieb Roman Cheplyaka: * Christian Maeder christian.mae...@dfki.de [2014-02-05 16:28:50+0100] This happens, because our /bin/sh is a real sh (and not a bash) that only allows to export LD_LIBRARY_PATH as a separate command. You mean it's a real sh and not a POSIX-compatible one. http://pubs.opengroup.org/onlinepubs/009695399/utilities/export.html Whatever it is, maybe it is a Korn Shell under (older) Solaris, it does not support: The Korn shell is where the `export NAME=value` syntax originated. I am tempted to suggest that we verify that this is still in current POSIX standards (the cited one is from 2004); POSIX recently dropped a significant number of Korn-shell-derived behaviors from the standard. This one is from 2013: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#export Roman signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: include a cabal-install executable in future GHC releases
* Herbert Valerio Riedel h...@gnu.org [2014-01-22 12:55:53+0100] On 2014-01-22 at 10:08:02 +0100, Henning Thielemann wrote: Am 22.01.2014 09:57, schrieb Herbert Valerio Riedel: On 2014-01-21 at 20:22:48 +0100, Ganesh Sittampalam wrote: I feel this blurs the roles of GHC and the Platform. IMO, that's a weak argument, as the roles are already blurred: GHC comes with `haddock`, `hp2ps`, and `hpc` executables which could be provided by the HP instead. At least haddock is bound to the specific GHC version. When I look at http://hackage.haskell.org/package/haddock, there are multiple versions, 2.12.0 and the 4 versions of 2.13.*, which are all declared to work with ghc == 7.6.*, that is, 5 haddock versions compatible with 3 released versions of GHC 7.6. So while it may be bound to a major version of the GHC API, haddock can obviously have more releases than GHC has releases (otherwise it could just carry GHC's version), and can therefore be updated. Henning could be more specific in his claim that haddock is bound to the specific GHC version. I guess he's referring to the binary rather than source distribution's compatibility. Assuming static linking w.r.t. the ghc package, the incompatibility with a different GHC version could still arise from the fact that haddock (as any other GHC API using application, I suppose) makes use of the GHC's lib directory, although I don't know the details. If we are talking about installing haddock from source (using cabal-install), then it should be no different from installing, say, ghc-mod. Roman signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: include a cabal-install executable in future GHC releases
Agreed, this would improve usability of binary GHC releases a lot, and I don't see any downsides. +1 Roman * Carter Schonwald carter.schonw...@gmail.com [2014-01-19 19:02:27-0500] Hey everyone, I'd like to propose that GHC releases 7.8.1 onwards include a cabal-install (aka cabal) executable, but not include the library deps of cabal-install that aren't already distributed with ghc.(unless ghc should have those deps baked in, which theres very very good reasons not to do.). currently if someone wants just a basic haskell install of the freshest ghc they have to install a ghc bindist, then do a boostrap build of cabal-install by hand (if they want to actually get anything done :) ). This is not a human friendly situation for folks who are new to haskell tooling, but want to try out haskell dev on a server style vm or the like! point being: It'd be great for haskell usability (and egads amounts of config time, even by seasoned users) the ghc bindists / installers included a cabal-install binary thoughts? -Carter ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GADT records revisited
I think this is intentional and conforms to the documentation. Your
constructors clearly have *different* result types, even though they
both can be instantiated from a single type scheme `FooBar x a`.
I'll leave it to others to comment on whether the generalization you
propose is reasonable and feasible.
Roman
* Philip K.F. Hölzenspies p.k.f.holzensp...@utwente.nl [2014-01-17
07:51:26+0100]
Dear all,
I was playing around with GADT-records again and ran into behaviour
that I'm not sure is intentional. Given this program:
{-#LANGUAGE GADTs #-}
data FooBar x a where
Foo :: { fooBar :: a } - FooBar Char a
Bar :: { fooBar :: a } - FooBar Bool a
GHC tells me this:
foo.hs:3:1:
Constructors Foo and Bar have a common field `fooBar',
but have different result types
In the data declaration for `FooBar'
Failed, modules loaded: none.
The user guide does say (section 7.4.7): However, for GADTs there is
the following additional constraint: every constructor that has a
field f must have the same result type (modulo alpha conversion). So
this behaviour is documented in the user guide. However, it seems
reasonable that in the case above, where all the relevant variables
are exposed in the result type of both constructors, this should be
perfectly typeable. In other words, shouldn't GHC be able to derive a
type that is simply:
fooBar :: FooBar x a - a
?
Is this something that was simply never implemented, but could be, or
is this not decidable or prohibitively computationally complex?
Regards,
Philip
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC error message on type mismatch
* Daniel Trstenjak daniel.trsten...@gmail.com [2013-11-08 05:54:49+0100] Perhaps: Couldn't match type `A' with `B´ Real type: B Given type: A Or instead of 'Given', like others have suggested: 'Provided' or 'Supplied'. So far in this thread I haven't seen any suggestions better than status quo. E.g.: Prelude (undefined :: Int - Bool) (undefined :: Bool) interactive:2:29: Couldn't match expected type `Int' with actual type `Bool' In the first argument of `undefined :: Int - Bool', namely `(undefined :: Bool)' In the expression: (undefined :: Int - Bool) (undefined :: Bool) In an equation for `it': it = (undefined :: Int - Bool) (undefined :: Bool) This one is quite clear — the compiler expected an argument of type Int, but it was of type Bool. Now replace this with Real and Given. Well, Bool for the function argument is both Real and Given (I gave it this type, and it became its real type). And calling Int either Real or Given doesn't make any sense. Roman signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] repa not running in parallel?
Try adding +RTS -N at the end of your ./Main command line. * Alexander Herz alexander.h...@mytum.de [2013-11-07 10:40:59+0100] Hi, I'm new to haskell and I tried to reproduce the perfomance values from the paper Regular, Shape-polymorphic, Parallel Arrays in Haskell. I modified the repa-mmult example from the repa-example package to use the mmultP from Data.Array.Repa.Algorithms.Matrix. Then I compile it with ghc -threaded -fglasgow-exts -O Main.hs but running it with two large matrices : ./Main -random 4096 4096 -random 4096 4096 I can see that only one of my 4 cpus is utilized. What am I doing wrong? Note: The unmodified repa-example also does not run in parallel. Thx, Alex ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell signature.asc Description: Digital signature ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: love for hpc?
So Evan's prediction was accurate ;-) * Carter Schonwald carter.schonw...@gmail.com [2013-11-07 00:29:24-0500] Evan, if you want to get involved in working on HPC, go for it! theres many many pieces of ghc that need more proactive ownership. i should probably use HPC a bit as i start getting my numerical libs out, and i'm sure future me will appreciate current you working on making it better -Carter On Thu, Nov 7, 2013 at 12:03 AM, Evan Laforge qdun...@gmail.com wrote: Is anyone out there using HPC? It seems like it was gotten into a more or less working if not ideal state, and then abandoned. Things I've noticed lately: The GHC runtime just quits on the spot if there's already a tix file. This bit me when I was parallelizing tests. It's also completely unsafe when run concurrently, mostly it just overwrites the file, sometimes it quits. Sure to cause headaches for someone trying to parallelize tests. You can't change the name of the output tix file, so I worked around by hardlinking the binary to a bunch of new ones, and then doing 'hpc sum' on the results. The hpc command is super slow. It might have to do with it doing its parsing with Prelude's 'read', and it certainly doesn't help the error msgs. And the whole thing is generally minimally documented. I can already predict the answer will be yes, HPC could use some love, roll up your sleeves and welcome! It does look like it could be improved a lot with just a bit of effort, but that would be a yak too far for me, at the moment. I'm presently just curious if anyone else out there is using it, and if they feel like it could do with a bit of polishing. ___ 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 signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] ordNub
* Anthony Cowley acow...@seas.upenn.edu [2013-10-12 15:43:57-0400] On Oct 12, 2013, at 2:47 PM, Niklas Hambüchen m...@nh2.me wrote: I would like to come back to the original question: How can ordNub be added to base? I guess we agree that Data.List is the right module for a function of type Ord a = [a] - [a], but this introduces * a cyclic dependency between Data.List and Data.Set * a base dependency on containers. What is the right way to go with that? Should ordNub be introduced as part of Data.Set, as Conrad suggested? It does not really have anything to do with Set, apart from being implemented with it. I think nub's behavior is rather set-related, so I don't really understand the objection to putting it in Data.Set. It's not Set (in the data structure sense) related. It's list-related, because it clearly acts on lists. Therefore, it belongs to Data.List. Besides, we already have the precedent of the slow nub being in Data.List. Roman signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: cabal upload -- error 404
If you really want to upload the package, then do cabal upload dist/PrimitiveArray-0.5.2.0.tar.gz (without -c). I'd guess that the new hackage server doesn't yet support the API required for -c. You can report this at https://github.com/haskell/cabal/issues although it will /probably/ end up at https://github.com/haskell/hackage-server/issues (Please also check that it isn't reported already.) Roman * Christian Hoener zu Siederdissen choe...@tbi.univie.ac.at [2013-10-09 16:32:17+0200] Hi everybody, Does anybody know what this means and how to resolve it? I have updated my hackage account and can upload via the web interface, just not via cabal. cabal config file is new as well. cabal upload -c dist/PrimitiveArray-0.5.2.0.tar.gz Checking dist/PrimitiveArray-0.5.2.0.tar.gz... Error: dist/PrimitiveArray-0.5.2.0.tar.gz: 404 Not Found Sorry for this being the wrong mailing list ;-) Many thanks, Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Using lenses
Hi Simon, An interesting use case is my time-lens library. http://hackage.haskell.org/package/time-lens-0.3/docs/Data-Time-Lens.html You can do things like modL minutes (+5) (TimeOfDay 16 57 13) 17:02:13 But one has to be somewhat lenient about the lens laws here. Roman * Simon Peyton-Jones simo...@microsoft.com [2013-10-03 08:07:12+] (I sent this to 'libraries' but Kim-Ee suggested adding Café, where so many smart people hang out.) Friends Some of you will know that I've promised to give a talk about Edward's lens libraryhttp://hackage.haskell.org/package/lens at the Haskell Exchangehttp://skillsmatter.com/event/scala/haskell-exchange in London next Wednesday (9th). I did this to give everyone (including me) a break from GHC hackery, and also to force me to learn about this lens voodoo that everyone is twittering about. Edward generously gave me quite a bit of one-to-one attention last week (my hair is still standing on end), but this message is to ask your help too. Specifically, I'd like to give some compelling use-cases. If you are using the lens library yourself, could you spare a few minutes to tell me how you are using it? I expect to cover Lens and Traversal but not Prism. The use-case everyone starts with is nested records, but I'd like to go beyond that. The next levels seem to be: · Lenses as views of data that isn't really there e.g. regarding a record with rectangular coordinates as having polar coordinates too. · Lenses and Traversals that focus on elements of finite maps (Control.Lens.At) What else? I'm sure you are using them in all sorts of cool ways that I would never think of, and I'd love to know. Please don't tell me anything secret! To give everyone the benefit I may just concatenate all the replies and send to you all, so please say if you don't want me to do that with yours. And don't burn too many cycles on this...I don't want to waste your time, and I can always get back to you if I can't understand what you say. Sooner is better than later...Weds is coming. Simon Edward's prophet PJ ___ Libraries mailing list librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANN] lvish 1.0 -- successor to monad-par
Ryan, You can use standalone-haddock[1] so that the links to other packages are not broken. [1]: http://documentup.com/feuerbach/standalone-haddock Roman * Ryan Newton rrnew...@gmail.com [2013-10-03 10:50:47-0400] Hi Ben, We made a small update releasehttp://hackage.haskell.org/package/lvish-1.0.0.2that links the github, and also links a mirror for the haddocks, since something weird seems to be going on with Hackage 2: http://www.cs.indiana.edu/~rrnewton/haddock/lvish/ https://github.com/iu-parfunc/lvars On Wed, Oct 2, 2013 at 1:05 PM, Ben Gamari bgamari.f...@gmail.com wrote: Ryan Newton rrnew...@gmail.com writes: Hi all, I'm pleased to announce the release of our new parallel-programming library, LVish: hackage.haskell.org/package/lvish It provides a Par monad similar to the monad-par package, but generalizes the model to include data-structures other than single-assignment variables (IVars). For example, it has lock-free concurrent data structures for Sets and Maps, which are constrained to only grow monotonically during a given runPar (to retain determinism). This is based on work described in our upcoming POPL 2014 paper: Do you have any aidea why the Haddocks don't yet exist. If I recall correctly, under Hackage 1 the module names wouldn't be made links until Haddock generation had completed. Currently the lvish modules' point to non-existent URLs. Also, is there a publicly accessible repository where further development will take place? Cheers, - Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] indentation with let and do
On Thu, Oct 3, 2013 at 9:44 PM, Brandon Allbery allber...@gmail.com wrote: On Thu, Oct 3, 2013 at 2:31 PM, Corentin Dupont corentin.dup...@gmail.com wrote: test :: Bool - IO () test foo = do let bar = case foo of True - Foo; False - Bar return () while this one does (just adding one space in front of True and False): test :: Bool - IO () test foo = do let bar = case foo of True - Foo; False - Bar return () Do you understand how layout works? Informally, something that is more indented is a continuation of the previous expression, while something equally or less indented is a new expression. In this case, the previous expression is `bar = case foo of` and indenting `True` to the same level as `bar` means you have ended the expression starting with `bar =`. Adding just one extra space indicates that it's still part of `bar =`. (ghc is actually being somewhat lenient here; strictly speaking, you are not indented beyond the `case` so it should have ended the `case` expression. ghc allows some sloppiness like this when there absolutely must be something else after, but there are limits mostly imposed by layout introducers like `let` and `do`.) Brandon, Indentation of 'case' itself doesn't matter. The layout is introduced by 'of', and then it's the indentation of the lexeme which follows 'of' that matters. So GHC is correct here. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Any precedent or plan for guaranteed-safe Eq and Ord instances?
* Heinrich Apfelmus apfel...@quantentunnel.de [2013-10-02 11:24:39+0200] In other words, equality of abstract data types is different from equality of algebraic data types (constructors). I don't think you'll ever be able to avoid this proof obligation that the public API of an abstract data type preserves equivalence, so that LVish will yield results that are deterministic up to equivalence. It still seems to fit nicely into Safe Haskell. If you are the implementor of an abstract type, you can do whatever you want in the Eq instance, declare your module as Trustworthy, and thus take the responsibility for soundness of that instance w.r.t. your public API. Roman signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Any precedent or plan for guaranteed-safe Eq and Ord instances?
* Tillmann Rendel ren...@informatik.uni-marburg.de [2013-10-02 13:19:38+0200] Hi, Roman Cheplyaka wrote: It still seems to fit nicely into Safe Haskell. If you are the implementor of an abstract type, you can do whatever you want in the Eq instance, declare your module as Trustworthy, and thus take the responsibility for soundness of that instance w.r.t. your public API. A possible problem with marking instance Eq as an unsafe feature is that many modules would be only Trustworthy instead of Safe. So if I don't trust the authors of a module (because I don't know them), I cannot safely use their code just because they implement their own Eq instance? That would go against my every purely functional module is automatically safe because the compiler checks that it cannot launch the missiles understanding of Safe Haskell. Actually, Eq instances are not unsafe per se, but only if I also use some other module that assumes certain properties about all Eq instances in scope. So in order to check safety, two independent modules (the provider and the consumer of the Eq instance) would have to cooperate. Good point! Roman signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Any precedent or plan for guaranteed-safe Eq and Ord instances?
* Stijn van Drongelen rhym...@gmail.com [2013-10-02 15:46:42+0200] I do think something has to be done to have an Eq and Ord with more strict laws. * Operators in Eq and Ord diverge iff any of their parameters are bottom. This outlaws the Eq instances of lists, trees, and other (co)recursive types. Furthermore, in this formulation, even Eq for tuples is illegal, because (undefined, something) == somethingElse is going to diverge. Roman signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lifting IO actions into Applicatives
* Tom Ellis tom-lists-haskell-cafe-2...@jaguarpaw.co.uk [2013-10-01 09:20:23+0100] On Tue, Oct 01, 2013 at 09:29:00AM +0200, Niklas Haas wrote: On Tue, 1 Oct 2013 02:21:13 -0500, John Lato jwl...@gmail.com wrote: It's not a solution per se, but it seems to me that there's no need for the Monad superclass constraint on MonadIO. If that were removed, we could just have class LiftIO t where liftIO :: IO a - t a and it would Just Work. One concern with this is that it's not exactly clear what the semantics are on LiftIO (is liftIO a liftIO b equal to liftIO (a b) or not?) and the interaction between LiftIO and Applicative/Monad would have to be some sort of ugly ad-hoc law like we have with Bounded/Enum etc. Shouldn't it be an *Applicative* constraint? class Applicative t = ApplicativeIO t where liftIO :: IO a - t a and require that liftIO (pure x) = pure x liftIO (f * x) = liftIO f * liftIO x Seems like ApplicativeIO makes more sense than MonadIO, which is unnecessarily restrictive. With planned Functor/Applicative/Monad shuffle, the former could completely replace the latter. Agreed, this makes perfect sense. It simply says that liftIO is an applicative homomorphism. Roman signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell.org design is broken
There is now a big white stripe in the Haskell.org's header (see the screenshot). Roman attachment: haskellorg.png signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Multi-param typeclass vs locally constrained typeclass methods
* Jacques Carette care...@mcmaster.ca [2013-09-18 08:21:51-0400] Could someone please explain what the difference (if any!), in semantics is between class Foo f = Bar f g where method1 :: f a - g a and class Bar' g where method2 :: Foo f = f a - g a Bar is more flexible than Bar'. If you have n types, you can write n^2 Bar instances (potentially having very different semantics) to convert between them. You can only write n Bar' instances, on the other hand. In these instances you can dispatch based on 'g' but not on 'f'. 'f' is abstract, and you only can access it through the Foo interface. So they are quite different. Roman signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] name lists
* Ben Gamari bgamari.f...@gmail.com [2013-09-17 10:03:41-0400]
Another approach might be to introduce some notion of a name list which
can appear in the export list. These lists could be built up by either
user declarations in the source module or in Template Haskell splices
and would serve as a way to group logically related exports. This
would allow uses such as (excuse the terrible syntax),
module HelloWorld ( namelist MyDataLenses
, namelist ArithmeticOps
) where
import Control.Lens
data MyData = MyData { ... }
makeLenses ''MyDataLenses
-- makeLenses defines a namelist called MyDataLenses
namelist ArithmeticOps (add)
add = ...
namelist ArithmeticOps (sub)
sub = ...
Hi Ben,
Isn't this subsumed by ordinary Haskell modules, barring the current
compilers' limitation that modules are in 1-to-1 correspondence with
files (and thus are somewhat heavy-weight)?
E.g. the above could be structured as
module MyDataLenses where
data MyData = MyData { ... }
makeLenses ''MyData
module HelloWorld (module MyDataLenses, ...) where
...
Roman
signature.asc
Description: Digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] name lists
* Ben Gamari bgamari.f...@gmail.com [2013-09-17 12:41:05-0400]
Roman Cheplyaka r...@ro-che.info writes:
* Ben Gamari bgamari.f...@gmail.com [2013-09-17 10:03:41-0400]
Another approach might be to introduce some notion of a name list which
can appear in the export list. These lists could be built up by either
user declarations in the source module or in Template Haskell splices
and would serve as a way to group logically related exports. This
would allow uses such as (excuse the terrible syntax),
Hi Ben,
Isn't this subsumed by ordinary Haskell modules, barring the current
compilers' limitation that modules are in 1-to-1 correspondence with
files (and thus are somewhat heavy-weight)?
E.g. the above could be structured as
module MyDataLenses where
data MyData = MyData { ... }
makeLenses ''MyData
module HelloWorld (module MyDataLenses, ...) where
...
True. Unfortunately I've not seen much motion towards relaxing this
limitation[1].
Cheers,
- Ben
[1] http://ghc.haskell.org/trac/ghc/ticket/2551
I guess there simply were not many use cases for that. This may be one.
At least if we are talking about changing the compiler anyway, it's
better to stick with a well-understood and standardized mechanism.
Roman
signature.asc
Description: Digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: New syntax for Haskell
* John Wiegley jo...@fpcomplete.com [2013-09-10 04:48:36-0500] Niklas Hambüchen m...@nh2.me writes: Code written in cucumber syntax is concise and easy to read concise |kənˈsīs|, adj. giving a lot of information clearly and in a few words; brief but comprehensive. Compare: Scenario: Defining the function foldl Given I want do define foldl Which has the type (in brackets) a to b to a (end of brackets), to a, to list of b, to a And my arguments are called f, acc, and l When l is empty Then the result better be acc Otherwise l is x cons xs Then the result should be foldl f (in brackets) f acc x (end of brackets) xs To: foldl :: (a - b - a) - a - [b] - a foldl f z [] = z foldl f z (x:xs) = foldl f (f z x) xs How is that more concise or preferable? I thought it was a joke. Roman signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC API + Cabal API + Cabal version checks: is there a way out?
The right solution for Cabal would be not to know anything about the GHC's database format at all. GHC and cabal communicate via a command line interface (`ghc-pkg dump` in our direction; `ghc-pkg update` in the other). So it would suffice to have a library which implements parsing and printing of the package description, and have that library shared between GHC and Cabal. (Which I think is more or less what you guys are suggesting, only I'd like to point out that we should be focusing on the protocol instead of the database format. The latter should be opaque.) Roman * Niklas Hambüchen m...@nh2.me [2013-09-06 22:42:28+0900] On Fri 06 Sep 2013 22:13:58 JST, Yuri de Wit wrote: The right solution, imho, is to review these dependencies and move the low level ones out into a separate package that is shared by both ghc and cabal and that will rarely change. The direct side effect of this is that ghc would not be tied directly to a specific cabal version and you would not have to deal with this issue. This sounds very right to me. There should be something that describes what a GHC package database is, as minimally as possible (perhaps even only the data types). In the end, ghc is the defining side here - cabal is only a tool that builds on top of these definitions. Then ghc could finally be decoupled from Cabal. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a little parsec enhancement
* Petr Pudlák petr@gmail.com [2013-09-05 11:18:25+0200] Unfortunately |ParsecT| constructor isn't exported so I'm not able to implement it outside /parsec/. No, but there's an 'mkPT' function which is equivalent to the ParsecT constructor. (Although I, too, wish the ParsecT constructor were exposed.) Roman signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] function arithmetic?
* Christopher Howard christopher.how...@frigidcode.com [2013-08-31 21:01:38-0800] Hi. I was just curious about something. In one of my math textbooks I see expressions like this f + g or (f + g)(a) where f and g are functions. What is meant is f(a) + g(a) Is there a way in Haskell you can make use of syntax like that (i.e., expressions like f + g and f * g to create a new function), perhaps by loading a module or something? Not the syntax, but the notion itself corresponds exactly to idiom brackets/applicative functors. In this case it's the Reader applicative. Roman signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tasty not compiling
* Thiago Negri evoh...@gmail.com [2013-08-29 22:27:47-0300] I can't install tasty with cabal. Anyone with the same issue or a fix? $ cabal install tasty ... Test\Tasty\Core.hs:147:11: Not in scope: `witness' You probably have a too old version of 'tagged'. I'll add the lower version bound on it. Meanwhile, just do cabal install tasty --constraint 'tagged =0.5' Roman signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A question about laziness and performance in document serialization.
* Kyle Hanson hanoo...@gmail.com [2013-08-20 18:23:48-0700] So I am not entirely clear on how to optimize for performance for lazy bytestrings. Currently I have a (Lazy) Map that contains large BSON values (more than 1mb when serialized each). I can serialize BSON documents to Lazy ByteStrings using Data.Binary.runPut. I then write this bytestring to a socket using Network.Socket.ByteString.Lazy. My question is this, if the Map object doesn't change (no updates) when it serializes the same document to the socket 2x in a row, does it re-evaluate the whole BSON value and convert it to a bytestring each time? Yes. Lets say I wanted to have a cache of bytestings so I have another Map object that has the serialized bytestrings that I populate it with every time the original BSON Map changes. Should the map be strict or lazy? This is the wrong question. The right question is, do you want the values be strict (evaluated) or lazy (kept unevaluated until required)? If you want values to be lazy, then you have to use the lazy Map. If you want values to be strict, then you may either use the strict Map, or still use the lazy Map but make sure that the values are evaluated when you place them in the map. Using the strict Map is probably a better idea, but the lazy Map lets you have finer control over what is lazy and what is forced (should you need it). Note that the lazy bytestring is just a lazy list of strict bytestrings. Even placing it in the strict map wouldn't force its evaluation. Should the bytestrings it stores be strict or lazy? For a cache, it makes sense to store strict bytestrings (unless they are so large that it may be hard to allocate that much of contiguous space). Lazy bytestrings are useful for streaming, when you use a chunk and then discard it. Using strict bytestrings doesn't imply that you want to store them evaluated. Depending on your circumstances, it may be a good idea to store strict bytestrings lazily, so that they do not take space and time until they are requested for the first time. Simply operating with the words lazy and strict may be very confusing, since they refer to different things in different contexts. Every time you read that something is lazy or strict, try to decipher it in terms of the basic evaluation properties. HTH, Roman signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hspec-test-framework - Run test-framework tests with Hspec
My answer to this and many similar questions regarding tasty is: - I am probably not going to work on this - but I would be happy to see someone doing it Note that hspec-test-framework is a separate package, and it didn't have to be written or even approved by Simon. Same here — please write more supplementary packages if you feel a need. Roman * Alfredo Di Napoli alfredo.dinap...@gmail.com [2013-08-18 15:18:07+0200] Hi Simon, this is an exciting news! May I ask the question that maybe is lurking in the shadow? Due to the recent announcement of Roman's tasty library, are there plans to basically release something similar to hspec-test-framework and hspec-test-framework-th but targeting tasty instead? Bye :) A. On 18 August 2013 14:50, Simon Hengel s...@typeful.net wrote: Hi, I just released hspec-test-framework[1] and hspec-test-framework-th[2] to Hackage. They can be used to run test-framework tests with Hspec unmodified. This can also be used to work around test-framework's incompatibility with QuickCheck-2.6 and base-4.7.0 ;) Have a look at the README for usage instructions: https://github.com/sol/hspec-test-framework#readme Cheers, Simon [1] http://hackage.haskell.org/package/hspec-test-framework [2] http://hackage.haskell.org/package/hspec-test-framework-th ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock multiple definitions
* Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk [2013-08-16 08:16:35+0100]
In the future, please try with more recent version of GHC.
This is no longer a parse error with HEAD or 7.6.3.
Uhm, actually there is, with 7.6.3.
% cat haddock.hs
-- Main
-- | Blah blah blah
(x, y, z) = (1, 2, 3)
% haddock haddock.hs
haddock.hs:4:1: parse error on input `('
% haddock --version
Haddock version 2.13.2, (c) Simon Marlow 2006
Ported to use the GHC API by David Waern 2006-2008
It's great that it's fixed in HEAD.
Roman
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock multiple definitions
In any case, it shouldn't fail with a parse error, since this is valid
Haskell.
Please file a ticket at http://trac.haskell.org/haddock (but first see
if it hasn't been reported before).
Roman
* jabolo...@google.com jabolo...@google.com [2013-08-15 15:24:23-0400]
Hi,
I am using
GHC: 6.12.1
Haddock: 2.6.0
and the following does not work with Haddock (GHC is fine!):
-- Main
-- | Blah blah blah
(x, y, z) = (1, 2, 3)
$ haddock ...
/tmp/Main.hs:2:0: parse error on input `('
Is this a bug? Or it's just not part of Haddock?
This seems like an interesting feature to document several definitions
together, for example, error codes:
-- | Syscall error codes for blah...
--
-- errA when blah
-- ...
(errA, errB, errC) = ...
Cheers,
Jose
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Log exceptions to eventlog
Hi Simon, The bug I'm looking into ([1]) is caused by the exceptions thrown by the RTS, namely NonTermination and BlockedIndefinitelyOnSTM. (It probably doesn't make sense to ask *who* sent the exception, but I'd still like to know to whom they were sent and when.) So simply modifying throwTo doesn't seem to be an option here (unless it is also used by the RTS?). [1]: https://github.com/feuerbach/tasty/issues/15 Roman * Simon Marlow marlo...@gmail.com [2013-08-13 15:53:46+0100] On 12/08/13 10:20, Roman Cheplyaka wrote: Hi, Is there any way to log asynchronous exceptions to the eventlog, including information on which thread sent the exception and to which thread it was sent? You can insert events yourself using Debug.Trace.traceEventIO. Adding some built-in events for throwTo would be a good idea, we don't currently have that (you could try adding it yourself if you like, it's not too hard). Cheers, Simon Or are there any other ways to get this information? Roman ___ 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
Log exceptions to eventlog
Hi, Is there any way to log asynchronous exceptions to the eventlog, including information on which thread sent the exception and to which thread it was sent? Or are there any other ways to get this information? Roman signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Module names from a function name
Hi, You can easily do this using the haskell-names library. See http://documentup.com/haskell-suite/haskell-names Roman * Jong-won Choi oz.jongwon.c...@gmail.com [2013-08-08 12:34:44+1000] Hi, I asked this question to beginner mailing list and no luck so far, so I'm trying here. How can I get all the module names which (re-)export a given function name? I'd like to fix Emacs Haskell mode - interactive documentation browser and I need the list of such module names. Thanks! - Jong-won ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tasty, a new testing framework
* Magnus Therning mag...@therning.org [2013-08-08 07:59:37+0200] On Mon, Aug 05, 2013 at 09:48:39PM +0300, Roman Cheplyaka wrote: I am pleased to announce the first release of tasty, a new testing framework for Haskell. It is meant to be a successor to test-framework (which is unmaintained). Tasty supports HUnit, SmallCheck, QuickCheck, and golden tests out of the box (through the standard packages), but it is very extensible, so you can write your own test providers. Please see the home page for more information: http://documentup.com/feuerbach/tasty Are there plans an equivalent of test-framework-th too? I don't have any plans to do that myself, but I welcome anyone who cares to create and maintain such a package. donri on reddit said that porting test-framework-th should be a simple matter of changing one import. Roman signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Installing wxHaskel on Snow Leopard
* Eduardo Sato eduardo.s...@gmail.com [2013-08-07 14:46:02-0300] Hello, guys. Has anybody tried to install wxhaskell on Snow Leopard? I followed these instructions: http://www.haskell.org/haskellwiki/WxHaskell/Mac , but got an error: src/haskell/Graphics/UI/WXCore/WxcClassesAL.hs:13085:1: Unacceptable argument type in foreign declaration: CInt When checking declaration: foreign import ccall safe static wxLogWindow_Create wxLogWindow_Create :: Ptr (TWindow a) - CWString - CBool - CBool - IO (Ptr (TLogWindow ())) src/haskell/Graphics/UI/WXCore/WxcClassesAL.hs:13085:1: Unacceptable argument type in foreign declaration: CInt When checking declaration: foreign import ccall safe static wxLogWindow_Create wxLogWindow_Create :: Ptr (TWindow a) - CWString - CBool - CBool - IO (Ptr (TLogWindow ())) Failed to install wxcore-0.90.0.3 cabal: Error: some packages failed to install: wx-0.90.0.1 depends on wxcore-0.90.0.3 which failed to install. wxcore-0.90.0.3 failed during the building phase. The exception was: ExitFailure 1 http://lpaste.net/91634 I'm using ghc 7.6.3. I've heard the above problems are related to GHC 7.6.3 being more pedantic about FFI declarations. Is there any way around it? Indeed, and it has nothing to do with Snow Leopard. You should ensure that the CInt data constructor is imported. Either patch it yourself, or have the package maintainer to fix it. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tasty, a new testing framework
It certainly can, but it doesn't do that yet. Should be very easy to fix, though. Patches are welcome. Roman * Jan Stolarek jan.stola...@p.lodz.pl [2013-08-07 10:00:36+0200] Sorry, my last email got sent too quickly. Anyway, continuing my thought. So QuickCheck can classify tests: +++ OK, passed 100 tests (29% Short) Can tasty display this classification info? That was a thing I missed a lot in test-framework and would probably motivate me to switch to tasty. Janek - Oryginalna wiadomość - Od: Roman Cheplyaka r...@ro-che.info Do: haskell-cafe@haskell.org Wysłane: wtorek, 6 sierpień 2013 22:51:57 Temat: Re: [Haskell-cafe] ANNOUNCE: tasty, a new testing framework * John Wiegley jo...@fpcomplete.com [2013-08-06 13:40:50-0500] Roman Cheplyaka r...@ro-che.info writes: I am pleased to announce the first release of tasty, a new testing framework for Haskell. It is meant to be a successor to test-framework (which is unmaintained). It would be nice to see a comparison of the various test frameworks and why one might select one over another. I use hspec currently (which also integrates with HUnit, QuickCheck, etc.), and couldn't tell at a glance what tasty might offer. And I particularly dislike writing tests inside of a gigantic list; I much prefer the monadic style of hspec. This has been discussed on reddit here: http://www.reddit.com/r/haskell/comments/1jr8lb/tasty_a_new_testing_framework_successor_to/cbhiz40 Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tasty, a new testing framework
You can find an example here: https://github.com/feuerbach/regex-applicative/blob/master/regex-applicative.cabal#L89 If you'd like to contribute a short README section based on that, please go ahead! :) Roman * Tikhon Jelvis tik...@jelv.is [2013-08-06 09:29:21-0400] Could you add some documentation on how to use this with cabal? I've found integrating tests with cabal unintuitive and poorly documented--to the point where I haven't really bothered! I've gotten it working before, but I would have to look it up again in the future. (I also didn't use a framework.) It would be awesome to see an example .cabal file along with your example test cases. thanks, -tikhon On Tue, Aug 6, 2013 at 1:53 AM, Roman Cheplyaka r...@ro-che.info wrote: * Carter Schonwald carter.schonw...@gmail.com [2013-08-05 16:58:37-0400] fair enough. I take it that you're also (implicitly) committing to maintaining this for the next few years? :) That's correct. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tasty, a new testing framework
* John Wiegley jo...@fpcomplete.com [2013-08-06 13:40:50-0500] Roman Cheplyaka r...@ro-che.info writes: I am pleased to announce the first release of tasty, a new testing framework for Haskell. It is meant to be a successor to test-framework (which is unmaintained). It would be nice to see a comparison of the various test frameworks and why one might select one over another. I use hspec currently (which also integrates with HUnit, QuickCheck, etc.), and couldn't tell at a glance what tasty might offer. And I particularly dislike writing tests inside of a gigantic list; I much prefer the monadic style of hspec. This has been discussed on reddit here: http://www.reddit.com/r/haskell/comments/1jr8lb/tasty_a_new_testing_framework_successor_to/cbhiz40 Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: tasty, a new testing framework
I am pleased to announce the first release of tasty, a new testing framework for Haskell. It is meant to be a successor to test-framework (which is unmaintained). Tasty supports HUnit, SmallCheck, QuickCheck, and golden tests out of the box (through the standard packages), but it is very extensible, so you can write your own test providers. Please see the home page for more information: http://documentup.com/feuerbach/tasty Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tasty, a new testing framework
* Andrey Chudnov achud...@gmail.com [2013-08-05 15:31:16-0400] On 08/05/2013 02:48 PM, Roman Cheplyaka wrote: (which is unmaintained). Has this been confirmed by the author/maintainer? I've sent a couple of emails to Max (one in January, one in April) and haven't heard anything from him. My patches, which he applied in January, are still not released. That's why I regard test-framework as unmaintained. You can also make your own impression by browsing github (commit activity, outstanding pull requests, open issues...) Is it a drop-in replacement for test-framework, e.g. if I substitute test-framework for tasty in my .cabal files, will it work? If not, could you provide a quick guide for porting? Not quite. At the very least, you'll have to change module names (Test.Framework - Test.Tasty, Test.Framework.Providers.HUnit - Test.Tasty.HUnit, ...), and wrap the top-level list of tests into a testGroup. If you have type signatures, you'll need to rename Test to TestTree. That should be enough in most cases. If you use plusTestOptions, you'll need to look up appropriate functions from Test.Tasty.Options. Also, is the current version (0.1) recommended for general use? I'd love to see people using it. But you should treat this as beta software. I am in the process of migrating my own packages to use Tasty. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tasty, a new testing framework
* Carter Schonwald carter.schonw...@gmail.com [2013-08-05 16:58:37-0400] fair enough. I take it that you're also (implicitly) committing to maintaining this for the next few years? :) That's correct. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why GHC is written in Happy and not a monadic parser library?
* Malcolm Wallace malcolm.wall...@me.com [2013-08-04 09:33:22+0100] On 3 Aug 2013, at 21:03, Jason Dagit wrote: Another con of using parsec that I forgot to mention in my previous email is that with Parsec you need to be explicit about backtracking (use of try). Reasoning about the correct places to put try is not always easy and parsec doesn't help you with the task. In my experience, this is the main bug that people run into when using parsec. Although the original question did not mention parsec explicitly, I find it disappointing that many people immediately think of it as the epitome of monadic combinator parsing. The power of good marketing, eh? There are so many other good parsing libraries out there. Parsec happened to cure some known space-leaks in rival libraries about the time of its release (2000 or so), but the main reason it is popular is simply because it was distributed alongside ghc for a long time. I would also add to this a catchy and well-marketed name, which is often used as a generic name for a parser combinator library. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rank N Kinds
That's because types that belong to most non-star kinds cannot have values. data Foo (a :: k) = Foo is okay, data Foo (a :: k) = Foo a is bad because there cannot be a field of type a :: k. So no, no useful examples exist, because you wouldn't be able to use such a data constructor even if you could declare it. Roman * Wvv vite...@rambler.ru [2013-07-31 11:40:17-0700] OMG! I still have 7.6.3. It has old Typeable. I misunderstood PolyKinds a bit. It looks like k /= **, k ~ ***... But we cannot use CloseKinds like data Foo (a::k) = Foo a -- catch an error Expected kind `OpenKind', but `a' has kind `k' with RankNKinds we could write: data Foo (a::**) = Foo a data Bar (a::***) = Bar a So, now the task is more easy: I'm asking for useful examples with CloseKinds with ** and higher, and any useful examples for *** and higher cheers, Wvv 29 Jul 2013 at 14:44:50, José Pedro Magalhães [via Haskell] (ml-node+s1045720n5733561...@n5.nabble.com) wrote: Hi, On Fri, Jul 26, 2013 at 10:42 PM, Wvv [hidden email] wrote: First useful use is in Typeable. In GHC 7.8 class Typeable (a::k) where ... == class Typeable (a ::**) where ... But we can't write data Foo (a::k)-(a::k)-* ... deriving Typeable Why not? This works fine in 7.7, as far as I know. Cheers, Pedro -- View this message in context: http://haskell.1045720.n5.nabble.com/Rank-N-Kinds-tp5733482p5733667.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock GSOC project progress
Hi Mateusz, This looks great — I'm especially excited about List entries no longer have to be separated by empty lines! However, the decision to use Attoparsec (instead of Parsec, say) strikes me as a bit odd, as it wasn't intended for parsing source code. In particular, I'm concerned with error messages this parser would produce. Roman * Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk [2013-07-30 23:35:45+0100] Greetings cafe, As some of you might know, I'm hacking on Haddock as part of Google Summer of Code. I was recently advised to create a blog and document some of what I have been doing recently. You can find the blog at [1] if you're interested. The first post goes over the work from the last month or so. Future posts should be shorter and on more specific topics. There's an overview of what has happened/changed/will change at the bottom of the post if you're short on time. Thanks. [1] - http://fuuzetsu.co.uk/blog ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is withAsync absolutely safe?
* Bertram Felgenhauer bertram.felgenha...@googlemail.com [2013-07-28 18:11:54+0200] Roman Cheplyaka wrote: Can withAsync guarantee that its child will be terminated if the thread executing withAsync gets an exception? To remind, here's an implementation of withAsync: withAsyncUsing :: (IO () - IO ThreadId) - IO a - (Async a - IO b) - IO b -- The bracket version works, but is slow. We can do better by -- hand-coding it: withAsyncUsing doFork = \action inner - do var - newEmptyTMVarIO mask $ \restore - do t - doFork $ try (restore action) = atomically . putTMVar var let a = Async t (readTMVar var) r - restore (inner a) `catchAll` \e - do cancel a; throwIO e cancel a return r I am interested in the case when an exception arrives which transfers control to 'cancel', and then another exception arrives to the same thread. Even though 'catchAll' (which is a type-restricted synonym for catch) masks the exception handler, 'throwTo' inside 'cancel' is interruptible (as stated by the documentation). Will this scenario lead to a thread leakage? Yes. I guess that 'cancel' should use 'uninterruptibleMask_', but it's a hard call to make (if an async action becomes unresponsive, do we want to risk not being able to deliver any exceptions to the controlling thread just because it wants to terminate the async action?) Fair point. What if we fork a new thread, shield it from exceptions using uninterruptibleMask_, and let it to kill every other thread (however long that may take)? It will change the semantics a bit (the cleanup will be asynchronous), but I'm not sure if it can be a problem. A hybrid (but complicated) approach should also be possible. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
throwTo semantics
The documentation for throwTo says: throwTo does not return until the exception has been raised in the target thread. The calling thread can thus be certain that the target thread has received the exception. This is a useful property to know when dealing with race conditions: eg. if there are two threads that can kill each other, it is guaranteed that only one of the threads will get to kill the other. I don't see how the last sentense follows. I understood it so that the implication throwTo has returned = exception has been delivered is true, but not the reverse. If my understanding is correct, then both exceptions could be delivered without any of throwTos returning. Or is it true that throwTo has returned = exception has been delivered ? Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: throwTo semantics
* Bertram Felgenhauer bertram.felgenha...@googlemail.com [2013-07-28 17:57:04+0200] Roman Cheplyaka wrote: The documentation for throwTo says: throwTo does not return until the exception has been raised in the target thread. The calling thread can thus be certain that the target thread has received the exception. This is a useful property to know when dealing with race conditions: eg. if there are two threads that can kill each other, it is guaranteed that only one of the threads will get to kill the other. I don't see how the last sentense follows. I agree that it does not follow logically, at least I don't see how. It is an additional guarantee that the implementation provides. I understood it so that the implication throwTo has returned = exception has been delivered is true, but not the reverse. If my understanding is correct, then both exceptions could be delivered without any of throwTos returning. Or is it true that throwTo has returned = exception has been delivered Yes, that's true, in the sense that if and only if the exception has been delivered, the thread is ready to run (i.e., not blocked), to continue right after the throwTo. The implication from left to right does not mean that the thread ever gets a chance to run again. The program may terminate, or the thread may receive another exception in the meantime. The latter can be prevented by masking exceptions. I hope that makes sense. Thanks Bertram, this makes perfect sense. I wonder if the docs should be updated to clarify this? Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell-cafe] Is withAsync absolutely safe?
Can withAsync guarantee that its child will be terminated if the thread executing withAsync gets an exception? To remind, here's an implementation of withAsync: withAsyncUsing :: (IO () - IO ThreadId) - IO a - (Async a - IO b) - IO b -- The bracket version works, but is slow. We can do better by -- hand-coding it: withAsyncUsing doFork = \action inner - do var - newEmptyTMVarIO mask $ \restore - do t - doFork $ try (restore action) = atomically . putTMVar var let a = Async t (readTMVar var) r - restore (inner a) `catchAll` \e - do cancel a; throwIO e cancel a return r I am interested in the case when an exception arrives which transfers control to 'cancel', and then another exception arrives to the same thread. Even though 'catchAll' (which is a type-restricted synonym for catch) masks the exception handler, 'throwTo' inside 'cancel' is interruptible (as stated by the documentation). Will this scenario lead to a thread leakage? Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec question
Think about this: if you always take only the first element, why do you need lists at all? Roman * C K Kashyap ckkash...@gmail.com [2013-07-24 19:56:29+0530] Dear Cafe, I am trying to implement[1] parsec in go using the Monadic Parser Combinators paper [2] . I've been able to implement plus bind and many While doing the implementation - I looked at bind closely bind :: Parser a - (a - Parser b) - Parser b p `bind` f = \inp - concat [f v inp' | (v,inp') - p inp] I wondered if the result needs the complete list - wouldn't just the first successful value suffice? Perhaps - p `bind` f = \inp - take 1 $ concat [f v inp' | (v,inp') - p inp] Will this miss out matches? Regards, Kashyap [1] https://github.com/ckkashyap/parsec/blob/master/parsec.go [2] Monadic Parser Combinators: Graham Hutton, Erik Meijer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec question
To construct such an example, you have to ask yourself: when can we get a
list of more than one element?
Consider this:
a = char 'a'
((a a) | a) a
Suppose that our input is aa. The result of ((a a) | a) would be
the list
[('a', ), ('a', a)]
If you proceed with the first element of the list, the overall parse
will fail. It can only succeed if you then try the second element.
By the way, you shouldn't confuse Parsec (the library) with the general
concept of parser combinators or the implementation from the paper you
reference. The above parse would fail in Parsec as well, despite the
fact that Parsec allows backtracking.
Roman
* Kashyap CK ckkash...@gmail.com [2013-07-24 08:38:53-0700]
There is reference in the paper that empty list indicates failure...so
could we just use it like Maybe? I'd like it very much if I could get
an example of a missed match by not using the complete match.
regards,
Kashyap
Sent from my Windows Phone
From: Roman Cheplyaka
Sent: 24/07/2013 8:19 PM
To: C K Kashyap
Cc: Haskell Cafe
Subject: Re: [Haskell-cafe] Parsec question
Think about this: if you always take only the first element, why do you
need lists at all?
Roman
* C K Kashyap ckkash...@gmail.com [2013-07-24 19:56:29+0530]
Dear Cafe,
I am trying to implement[1] parsec in go using the Monadic Parser
Combinators paper [2] . I've been able to implement plus bind and
many
While doing the implementation - I looked at bind closely
bind :: Parser a - (a - Parser b) - Parser b
p `bind` f = \inp - concat [f v inp' | (v,inp') - p inp]
I wondered if the result needs the complete list - wouldn't just the first
successful value suffice?
Perhaps -
p `bind` f = \inp - take 1 $ concat [f v inp' | (v,inp') - p inp]
Will this miss out matches?
Regards,
Kashyap
[1] https://github.com/ckkashyap/parsec/blob/master/parsec.go
[2] Monadic Parser Combinators: Graham Hutton, Erik Meijer
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Deriving with generics without values
Forgot to mention — a good explanation of GHC Generics is the paper
A Generic Deriving Mechanism for Haskell.
Roman
* Roman Cheplyaka r...@ro-che.info [2013-07-14 18:21:58+0300]
Hi,
(Redirecting this back to cafe to keep it discoverable — hope you don't
mind.)
* JP Moresmau jpmores...@gmail.com [2013-07-14 16:02:56+0200]
Hello, sorry to bother you after you've been kind enough to answer me on
the list! I've looked a the smallcheck code but I don't see how to apply it
to my issue. First of all, I can't find the definition of - that you use
for example in ~. I suppose I'm doing something silly...
That comes from LogicT. - is almost the same as =, and ~ is almost
the same as *. Byt that's not relevant to the generic aspect of the
code.
But then, if I understand the code, the instances for GSerial rebuild
a type definition that mimicks the one passed as type argument, using
the final values (under the K1s) to generate a series. But in my case,
I want to be able to extract information from the original type, I'm
not just interested in the final value. What I want to be able is to
extract for example the constructor name and do something with it. I
don't see how to achieve that with your system.
Yes, it doesn't do everything that you want to do, but it shows the
idea.
The information you need is all there — for example, to get the
constructor name, you need to get hold of the C1 type (which is a
synonym for M1 C), and then call the conName method.
Lest you get lost in all this, it is useful to visualize the generic
representation by running your code through -ddump-deriv. Here's an
example:
% ghci -XDeriveGeneric -ddump-deriv -dsuppress-module-prefixes
Prelude GHC.Generics data T a = A { a :: a } | B | C deriving Generic
Derived instances
Derived instances:
instance Generic (T a_ao7) where
from (A g1_aph) = M1 (L1 (M1 (M1 (K1 g1_aph
from B = M1 (R1 (L1 (M1 U1)))
from C = M1 (R1 (R1 (M1 U1)))
to (M1 (L1 (M1 (M1 (K1 g1_api) = A g1_api
to (M1 (R1 (L1 (M1 U1 = B
to (M1 (R1 (R1 (M1 U1 = C
instance Datatype D1T where
datatypeName _ = T
moduleName _ = :Interactive
instance Constructor C1_0T where
conName _ = A
conIsRecord _ = True
instance Constructor C1_1T where conName _ = B
instance Constructor C1_2T where conName _ = C
instance Selector S1_0_0T where selName _ = a
Generic representation:
Generated datatypes for meta-information:
D1T
C1_0T
C1_1T
C1_2T
S1_0_0T
Representation types:
type Rep (T a_ao7) = D1
D1T
(C1 C1_0T (S1 S1_0_0T (Rec0 a_ao7))
:+: (C1 C1_1T U1 :+: C1 C1_2T U1))
This should give you an idea about how the structure you're dealing with
looks like, and where the important information resides.
I've also look at Aeson with the generic JSON parsing, but that's
using SYB which is again different, and SYB doesn't seem to provide
the types of the constructor fields, which I would need too...
It provides the types of the constructor fields through the Typeable
class, which may or may not be sufficient for your needs... Anyway,
you're right in that it is a completely different approach.
Roman
On Fri, Jul 12, 2013 at 10:57 AM, Roman Cheplyaka r...@ro-che.info wrote:
Well, in your case, you need not 'from', but 'to', in order to convert
from a generic representation to yours.
Take a look at how a similar task is done in SmallCheck:
https://github.com/feuerbach/smallcheck/blob/master/Test/SmallCheck/Series.hs#L180
https://github.com/feuerbach/smallcheck/blob/master/Test/SmallCheck/Series.hs#L352
Roman
* JP Moresmau jpmores...@gmail.com [2013-07-12 10:45:39+0200]
Hello all,
My problem is the following: I have my own data types, and I'd like to
derive automatically instances of some type class from them. I've
started
looking at GHC.Generics, which offer tools to do exactly that. However,
some functions of my typeclass do not take my data type as a parameter,
but
as a result. Basically:
class MyClass where
fromString :: String - a
data MyData=MkMyData {
myField ::Int
} deriving (Generic)
and I want to automatically generate the instance instance MyClass
MyData,
using default methods, etc.
The GHC Generic class does say that it uses a from function that convert
from the datatype to its representation: from :: a -
Rep
http://www.haskell.org/ghc/docs/7.4.1/html/libraries/ghc-prim-0.2.0.0/GHC-Generics.html#t:Rep
a
xfrom :: a - Rep
http://www.haskell.org/ghc
Re: [Haskell-cafe] ordNub
Something like that should definitely be included in Data.List. Thanks for working on it. Roman * Niklas Hambüchen m...@nh2.me [2013-07-14 19:20:52+0800] tldr: nub is abnormally slow, we shouldn't use it, but we do. As you might know, Data.List.nub is O(n²). (*) As you might not know, almost *all* practical Haskell projects use it, and that in places where an Ord instance is given, e.g. happy, Xmonad, ghc-mod, Agda, darcs, QuickCheck, yesod, shake, Cabal, haddock, and 600 more (see https://github.com/nh2/haskell-ordnub). I've taken the Ord-based O(n * log n) implementation from yi using a Set: ordNub :: (Ord a) = [a] - [a] ordNub l = go empty l where go _ [] = [] go s (x:xs) = if x `member` s then go s xs else x : go (insert x s) xs and put benchmarks on http://htmlpreview.github.io/?https://github.com/nh2/haskell-ordnub/blob/1f0a2c94a/report.html (compare `nub` vs `ordNub`). `ordNub` is not only in a different complexity class, but even seems to perform better than nub for very small numbers of actually different list elements (that's the numbers before the benchmark names). (The benchmark also shows some other potential problem: Using a state monad to keep the set instead of a function argument can be up to 20 times slower. Should that happen?) What do you think about ordNub? I've seen a proposal from 5 years ago about adding a *sort*Nub function started by Neil, but it just died. (*) The mentioned complexity is for the (very common) worst case, in which the number of different elements in the list grows with the list (alias you don't have an N element list with always only 5 different things inside). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Deriving with generics without values
Hi,
(Redirecting this back to cafe to keep it discoverable — hope you don't
mind.)
* JP Moresmau jpmores...@gmail.com [2013-07-14 16:02:56+0200]
Hello, sorry to bother you after you've been kind enough to answer me on
the list! I've looked a the smallcheck code but I don't see how to apply it
to my issue. First of all, I can't find the definition of - that you use
for example in ~. I suppose I'm doing something silly...
That comes from LogicT. - is almost the same as =, and ~ is almost
the same as *. Byt that's not relevant to the generic aspect of the
code.
But then, if I understand the code, the instances for GSerial rebuild
a type definition that mimicks the one passed as type argument, using
the final values (under the K1s) to generate a series. But in my case,
I want to be able to extract information from the original type, I'm
not just interested in the final value. What I want to be able is to
extract for example the constructor name and do something with it. I
don't see how to achieve that with your system.
Yes, it doesn't do everything that you want to do, but it shows the
idea.
The information you need is all there — for example, to get the
constructor name, you need to get hold of the C1 type (which is a
synonym for M1 C), and then call the conName method.
Lest you get lost in all this, it is useful to visualize the generic
representation by running your code through -ddump-deriv. Here's an
example:
% ghci -XDeriveGeneric -ddump-deriv -dsuppress-module-prefixes
Prelude GHC.Generics data T a = A { a :: a } | B | C deriving Generic
Derived instances
Derived instances:
instance Generic (T a_ao7) where
from (A g1_aph) = M1 (L1 (M1 (M1 (K1 g1_aph
from B = M1 (R1 (L1 (M1 U1)))
from C = M1 (R1 (R1 (M1 U1)))
to (M1 (L1 (M1 (M1 (K1 g1_api) = A g1_api
to (M1 (R1 (L1 (M1 U1 = B
to (M1 (R1 (R1 (M1 U1 = C
instance Datatype D1T where
datatypeName _ = T
moduleName _ = :Interactive
instance Constructor C1_0T where
conName _ = A
conIsRecord _ = True
instance Constructor C1_1T where conName _ = B
instance Constructor C1_2T where conName _ = C
instance Selector S1_0_0T where selName _ = a
Generic representation:
Generated datatypes for meta-information:
D1T
C1_0T
C1_1T
C1_2T
S1_0_0T
Representation types:
type Rep (T a_ao7) = D1
D1T
(C1 C1_0T (S1 S1_0_0T (Rec0 a_ao7))
:+: (C1 C1_1T U1 :+: C1 C1_2T U1))
This should give you an idea about how the structure you're dealing with
looks like, and where the important information resides.
I've also look at Aeson with the generic JSON parsing, but that's
using SYB which is again different, and SYB doesn't seem to provide
the types of the constructor fields, which I would need too...
It provides the types of the constructor fields through the Typeable
class, which may or may not be sufficient for your needs... Anyway,
you're right in that it is a completely different approach.
Roman
On Fri, Jul 12, 2013 at 10:57 AM, Roman Cheplyaka r...@ro-che.info wrote:
Well, in your case, you need not 'from', but 'to', in order to convert
from a generic representation to yours.
Take a look at how a similar task is done in SmallCheck:
https://github.com/feuerbach/smallcheck/blob/master/Test/SmallCheck/Series.hs#L180
https://github.com/feuerbach/smallcheck/blob/master/Test/SmallCheck/Series.hs#L352
Roman
* JP Moresmau jpmores...@gmail.com [2013-07-12 10:45:39+0200]
Hello all,
My problem is the following: I have my own data types, and I'd like to
derive automatically instances of some type class from them. I've started
looking at GHC.Generics, which offer tools to do exactly that. However,
some functions of my typeclass do not take my data type as a parameter,
but
as a result. Basically:
class MyClass where
fromString :: String - a
data MyData=MkMyData {
myField ::Int
} deriving (Generic)
and I want to automatically generate the instance instance MyClass
MyData,
using default methods, etc.
The GHC Generic class does say that it uses a from function that convert
from the datatype to its representation: from :: a -
Rep
http://www.haskell.org/ghc/docs/7.4.1/html/libraries/ghc-prim-0.2.0.0/GHC-Generics.html#t:Rep
a
xfrom :: a - Rep
http://www.haskell.org/ghc/docs/7.4.1/html/libraries/ghc-prim-0.2.0.0/GHC-Generics.html#t:Rep
a
x
But I don't have a a to start from! I see from the related papers that
the automatically generated code from from actually does pattern matches
on
constructors, so I need a value, undefined won't work. However I see
Re: [Haskell-cafe] Quick-check: how to generate arbitrary complex data?
* martin martin.drautzb...@web.de [2013-07-13 10:10:39+0200] Am 07/12/2013 09:18 AM, schrieb Roman Cheplyaka: QuickCheck's Gen is a functor. So you can generate a list, and then use fmap to add a hash to it. instance Arbitrary HashedList where arbitrary = addHashToList $ arbitrary This requires HashedList to be a new type, right? So far my code only used type synonyms. Does this mean I have to convert type synonyms into types in order to use QuickCheck? Probably. Technically, you could use OverlappingInstances to provide a special case for your lists (because they have a spcific shape), but I'd consider it a kludge in this case. Or you can avoid defining an instance at all, as Aleksey has pointed out. Does this mean I have to plan for QuickCheck when I design my types? Kind of. It's not really specific to QuickCheck. Every time you want to give some non-standard instances to your types, you should be using newtypes or data-types. More generally, you should be using newtypes or data types every time when you introduce a non-trivial abstraction that isn't described by the standard types. You case is a good example of that. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] getting haddock to cooperate with cpp
This is not true either. Cabal preprocesses files that explicitly
indicate (via an extension) that they need to be preprocessed.
For example, a .cpphs file will be preprocessed to yield an .hs file.
.hs files are never preprocessed by Cabal, as far as I can tell.
If you have an .hs file with {-# LANGUAGE CPP #-}, it is a compiler's
job to detect it and run the preprocessor.
But haddock uses the GHC API (which knows how to do the above), so there
shouldn't be issues with that.
Roman
* Felipe Almeida Lessa felipe.le...@gmail.com [2013-07-12 18:34:32-0300]
I guess that cabal preprocesses the files before calling Haddock then.
Perhaps that's why it asks me to `cabal configure` before `cabal
haddock`ing =). If you're able to switch over to cabal, that may be
the easiest solution.
Cheers,
On Fri, Jul 12, 2013 at 6:31 PM, Evan Laforge qdun...@gmail.com wrote:
I'm calling haddock myself. Cabal might have some special magic for CPP,
when I searched for haddock CPP I got some old bugs about adding cabal
support. So presumably it's possible.
On Jul 12, 2013 1:15 PM, Felipe Almeida Lessa felipe.le...@gmail.com
wrote:
Are you using `cabal haddock` or calling haddock manually?
Cheers,
On Fri, Jul 12, 2013 at 3:25 PM, Evan Laforge qdun...@gmail.com wrote:
So haddock ignores {-# LANGUAGE CPP #-}, which makes it crash on any
file that uses it. But if you pass --optghc=-cpp, it runs CPP on
everything, which makes it crash on any file that uses string gaps, or
happens to contain a /*. /* is rare and easily fixed, but not string
gaps.
It looks like a workaround would be to manually inspect the files for
LANGUAGE CPP and run two haddock passes, but then I would have to get
the two passes to cooperate creating a single TOC and index.
Isn't there some way to run haddock on files that use CPP?
In the broader scheme, it seems perverse to be using CPP in the first
place. I use it to configure imports and exports, e.g. to swap out a
driver backend on different OSes, and to export more symbols when
testing. Would it make sense to have a haskell version of CPP that
provides only these features (e.g. just #ifdef, #else, #endif, and
#define) and leaves out the problematic C comments and backslash
expectations?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Felipe.
--
Felipe.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] build failure on Hackage
* Brian Lewis br...@lorf.org [2013-07-13 14:30:01-0500] I maintain a library that, on Linux, needs libXxf86vm to build. The server where Hackage runs doesn't have that library, so the build fails. I think this is reasonable -- that box can't possibly have all the libraries various packages might need. But the build failure seems to cause the Haddock docs to not be generated. Why? This is a consequence of how haddock works. It uses GHC API, which has to compile modules before haddock can process them. My understanding is, if someone specifies my library as a build dependency, my library's build failure will also cause the docs for their package not to be built. I think my library will kill the Hackage Haddock docs for any other package that depends on it, due to a build error that's not even meaningful. What can I do? 1. Why exactly does haddock fail? IINM, the absence of library itself (i.e. an .a or .so file) shouldn't be a problem, as haddock doesn't do linking. If the problem is due to an absent include file, perhaps you can bundle it with your package for the sake of generating documentation? To generate documentation without linking, do cabal configure cabal haddock instead of cabal install 2. You can use standalone-haddock to generate the documentation on a system where the library is installed and then upload it to your own web host. Unfortunately, this won't solve the problem with reverse deps (but they could do the same). 3. If we ever switch to Hackage 2, this problem should be solved by user-uploadable docs. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] build failure on Hackage
* Brian Lewis br...@lorf.org [2013-07-13 15:44:58-0500] On 2013.07.13, at 23:15, Roman Cheplyaka wrote: 1. Why exactly does haddock fail? I think it never actually tries to build the Haddock docs for the actual package of interest because its dependencies failed to build. Here's the GLFW-b build log: http://hackage.haskell.org/packages/archive/GLFW-b/1.0.0/logs/failure/ghc-7.6 ... Running Haddock for bindings-DSL-1.0.16... ... Running Haddock for th-lift-0.5.5... ... * Missing C library: Xxf86vm These messages are from the build of bindings-GLFW, a dependency of GLFW-b. Due to the missing library, bindings-GLFW's build fails. So GLFW-b's does too. I guess I think the build failure should be noted, but that Hackage should go on and build the docs anyway. Ah, yes. This may be a bit more complicated than it seems, due to the way Cabal works. Let's say you've built the docs for this library. Now you have to install it, so that its reverse dependencies can reference it. Installation involves registering the package, so that Cabal can later see which packages are installed. Here's the catch: package databases are maintained by compilers, not by Cabal. In the common case this means GHC. (Unfortunately, haddock is not a separate compiler, which would be a more proper solution.) So we must register the package with GHC. But then we cannot distinguish between real and docs-only packages. Cabal and GHC would expect package to be installed, and would happily attempt to build other packages against it, and fail miserably. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Quick-check: how to generate arbitrary complex data?
* martin martin.drautzb...@web.de [2013-07-12 08:33:54+0200] Hello all, I have a type (Mail) which consists of hash and a list, where the hash keeps some redundant data of the list for faster access. I can add and remove elements to values of this type using custom functions, called push and pop. Now I wanted to write some quick checks, but I have no clue how to generate arbitrary values of this type. It will certainly no suffice to write arbitrary instances for the underlying types (Int and Char), because the hash and the list need to be synchronized. Currently Mail it is only a type synonym. I suppose as a prerequisite I need to wrap it into a type constructor. But then what? QuickCheck's Gen is a functor. So you can generate a list, and then use fmap to add a hash to it. instance Arbitrary HashedList where arbitrary = addHashToList $ arbitrary Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Deriving with generics without values
Well, in your case, you need not 'from', but 'to', in order to convert
from a generic representation to yours.
Take a look at how a similar task is done in SmallCheck:
https://github.com/feuerbach/smallcheck/blob/master/Test/SmallCheck/Series.hs#L180
https://github.com/feuerbach/smallcheck/blob/master/Test/SmallCheck/Series.hs#L352
Roman
* JP Moresmau jpmores...@gmail.com [2013-07-12 10:45:39+0200]
Hello all,
My problem is the following: I have my own data types, and I'd like to
derive automatically instances of some type class from them. I've started
looking at GHC.Generics, which offer tools to do exactly that. However,
some functions of my typeclass do not take my data type as a parameter, but
as a result. Basically:
class MyClass where
fromString :: String - a
data MyData=MkMyData {
myField ::Int
} deriving (Generic)
and I want to automatically generate the instance instance MyClass MyData,
using default methods, etc.
The GHC Generic class does say that it uses a from function that convert
from the datatype to its representation: from :: a -
Rephttp://www.haskell.org/ghc/docs/7.4.1/html/libraries/ghc-prim-0.2.0.0/GHC-Generics.html#t:Rep
a
xfrom :: a -
Rephttp://www.haskell.org/ghc/docs/7.4.1/html/libraries/ghc-prim-0.2.0.0/GHC-Generics.html#t:Rep
a
x
But I don't have a a to start from! I see from the related papers that
the automatically generated code from from actually does pattern matches on
constructors, so I need a value, undefined won't work. However I see the
GHC.Generics also provide :+: (Sums: encode choice between constructors).
If I have to provide an value, then the choice between constructor has been
done! The examples about generics on
http://www.haskell.org/haskellwiki/GHC.Generics do provide an example of
defining the instance for :+: but I don't understand how we can get there.
If I have a class method that takes a value as a parameter, and I pass
undefined to it, the code will crash, since it can't pattern match on
undefined.
Can somebody shed some light on this? Am I using the wrong tool for the
job? How can I achieve what I want? I want the full type representation
with sums, but without a value to start from.
Thanks a million!
JP
--
JP Moresmau
http://jpmoresmau.blogspot.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] getting haddock to cooperate with cpp
* Evan Laforge qdun...@gmail.com [2013-07-12 14:25:00-0400]
So haddock ignores {-# LANGUAGE CPP #-}, which makes it crash on any
file that uses it.
I'm pretty sure it's not true in general.
If you click on the Source link at this haddock page:
http://hackage.haskell.org/packages/archive/smallcheck/0.6.2/doc/html/Test-SmallCheck-Series.html
you'll see that CPP is used there.
Roman
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comparing functions
* Vlatko Basic vlatko.ba...@gmail.com [2013-07-11 19:33:38+0200]
Hello Cafe,
I have
data CmpFunction a = CF (a - a - Bool)
that contains comparing functions, like ==, , ..., and I'm trying
to declare the Show instance for it like this
instance Show (CmpFunction a) where
show (CF (==)) = ==-- no good
show f = case f of-- no good also
CBF (==) - ==
_ - Other
but compiler complains for both with
This binding for `==' shadows the existing binding
imported from `Prelude' at src/Main.hs:6:8-11
(and originally defined in `ghc-prim:GHC.Classes')
Is it possible at all to compare two functions or how to solve this
problem, to show some string for a specific function?
Depending on why you need that...
{-# LANGUAGE FlexibleContexts, UndecidableInstances, FlexibleInstances #-}
import Test.SmallCheck
import Test.SmallCheck.Series
import Test.SmallCheck.Drivers
import Control.Monad.Identity
import Data.Maybe
data CmpFunction a = CF (a - a - Bool)
feq :: (Show a, Serial Identity a) = CmpFunction a - CmpFunction a - Bool
feq (CF f1) (CF f2) =
isNothing $
runIdentity $
smallCheckM 10 (\x1 x2 - f1 x1 x2 == f2 x1 x2)
instance Show (CmpFunction Integer) where
show f
| f `feq` CF (==) = ==
| f `feq` CF (/=) = /=
| f `feq` CF () =
| f `feq` CF (=) = =
| otherwise = Unknown function
This uses SmallCheck to figure out, with some degree of certainty,
whether two functions are equal.
Of course, Rice's theorem still holds, and the above instance is easy
to fool, but it still might be useful in some cases.
Roman
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec error message not making any sense
Please check your code. I had two problems with it: mixed tabs and spaces, and undefined 'quotedChar'. After defining quotedChar = anyChar, I get a different error message from yours: *Main parseFromFile textgridfile testdata.TextGrid Left testdata.TextGrid (line 137, column 1): unexpected end of input expecting quote at end of cell Roman * Fredrik Karlsson dargo...@gmail.com [2013-07-09 08:07:24+0200] Hi Roman, I'm using parsec-3.1.3 I put the code in a gist here - sorry about that. https://gist.github.com/dargosch/5955045 Fredrik On Tue, Jul 9, 2013 at 12:08 AM, Roman Cheplyaka r...@ro-che.info wrote: Hi Fredrik, First, do you use the latest parsec version (3.1.3)? If not, can you try the same with 3.1.3? Second, please upload your code to hpaste.org or a similar service and give us the link. It's not much fun to extract code from an html email. Roman * Fredrik Karlsson dargo...@gmail.com [2013-07-08 23:54:17+0200] Dear list, I have a Parsec parser that fails and gives the following error message: *Main parseFromFile textgridfile testFile Left /Users/frkkan96/Documents/src/ume/umecore/testing/testdata/testdata.TextGrid (line 35, column 5): unexpected t expecting intervals [ Now, this is perfectly understandable, but line 35, col 5 in the file being parsed looks like the supplies image - there is no 't' there. Any ideas on what is going on? The parser I am using is: data VariableLine = VariableLine String String deriving Show data TierType = IntervalTier | PointTier deriving Show data Tier = Tier String deriving Show data LabelFile = LabelFile Double Double deriving Show data Label = Label String TierType Double Double String deriving Show haskelldef = makeTokenParser haskellDef textgridfile :: Parser (LabelFile, [[Label]]) textgridfile = do h - header ll - many1 tier return $ (h,ll) header :: Parser LabelFile header = do string headTS1 start - try (float haskelldef) | (fmap fromInteger $ integer haskelldef ) string xmax = end - try (float haskelldef) | (fmap fromInteger $ integer haskelldef ) string tiers? exists \n string size = integer haskelldef string item []: whiteSpace haskelldef return $ LabelFile start end tier :: Parser [Label] tier = do whiteSpace haskelldef string item [ integer haskelldef string ]: whiteSpace haskelldef try (string class = \IntervalTier\) | string class = \TextTier\ whiteSpace haskelldef string name = char '' name - many quotedChar char '' ? quote at end of cell whiteSpace haskelldef string xmin = try (float haskelldef) | (fmap fromInteger $ integer haskelldef ) whiteSpace haskelldef string xmax = try (float haskelldef) | (fmap fromInteger $ integer haskelldef ) string intervals: size = | string points: size = integer haskelldef whiteSpace haskelldef labelList - many1 (interval name) return $ labelList interval :: String - Parser Label interval tierName = do whiteSpace haskelldef string intervals [ integer haskelldef string ]: whiteSpace haskelldef string xmin = start - try (float haskelldef) | (fmap fromInteger $ integer haskelldef ) whiteSpace haskelldef string xmax = end - try (float haskelldef) | (fmap fromInteger $ integer haskelldef ) whiteSpace haskelldef string text = char '' text - many quotedChar char '' ? quote at end of cell return $ Label tierName IntervalTier start end text which fails on the attached input file. I can't see how 't' is found?? What am I doing wrong? /Fredrik -- Life is like a trumpet - if you don't put anything into it, you don't get anything out of it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Life is like a trumpet - if you don't put anything into it, you don't get anything out of it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Understanding version differences
The compiler defaults the kind of 'quality' (i.e. the first argument of
QUALITIES) to *, not being able to infer it from the class definition
itself (and other definitions that it references).
Since you want it to have kind * - *, you should enable KindSignatures
and add an annotation, or otherwise disambiguate the kind.
This behaviour follows the Haskell Report. The change from previous
versions of GHC is documented here:
http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/release-7-4-1.html#id3015054
Roman
* Patrick Browne patrick.bro...@dit.ie [2013-07-09 12:45:19+0100]
Hi,
The code [1] below compiles and runs with GHCi version 7.0.4.
I get one warning and an error message with GHCi version 7.6.1.
1) Warning -XDatatypeContexts is deprecated. Unless there are
propagation effects, this is well explained.
2) foom-1.hs:65:15:
`quality' is applied to too many type arguments
In the type `quality entity - agent - IO Observation'
In the class declaration for `OBSERVERS'
Failed, modules loaded: none.
I do not understand the error message from 7.6.1.
I am not too interested actually fixing it, I just want to understand
it.
Thanks,
Pat
[1]The code is from: A Functional Ontology of Observation and
Measurement Werner Kuhn
{-# LANGUAGE DatatypeContexts,MultiParamTypeClasses #-}
module ENDURANTS where
import System.Time
type Id = String
type Position = Integer
type Moisture = Float
type Celsius = String
type Heat = Float
data WeatherStation = WeatherStation Id Position deriving Show
data Value = Boolean Bool | Count Int | Measure Float | Category String
deriving Show
data Observation = Observation Value Position ClockTime deriving Show
data AmountOfAir = AmountOfAir Heat Moisture deriving Show
muensterAir = AmountOfAir 10.0 70.0
class ENDURANTS endurant where
-- must add instances all down the hierarchy for each instance
instance ENDURANTS WeatherStation where
instance ENDURANTS AmountOfAir where
class ENDURANTS physicalEndurant = PHYSICAL_ENDURANTS physicalEndurant
where
instance PHYSICAL_ENDURANTS WeatherStation where
instance PHYSICAL_ENDURANTS AmountOfAir where
class PHYSICAL_ENDURANTS amountOfMatter = AMOUNTS_OF_MATTER
amountOfMatter where
instance AMOUNTS_OF_MATTER WeatherStation where
class PHYSICAL_ENDURANTS physicalObject = PHYSICAL_OBJECTS
physicalObject where
instance PHYSICAL_OBJECTS WeatherStation where
class PHYSICAL_OBJECTS apo = APOS apo where
getPosition :: apo - Position
instance APOS WeatherStation where
getPosition (WeatherStation iD pos) = pos + 10
-- a data type declaration and data type constructor.
data PHYSICAL_ENDURANTS physicalEndurant = Temperature
physicalEndurant = Temperature physicalEndurant deriving Show
-- Qualities the class of all quality types (= properties) is a
constructor class
-- its constructors can be applied to endurants, perdurants, qualities
or abstracts
class QUALITIES quality entity
instance QUALITIES Temperature AmountOfAir
class (APOS agent, QUALITIES quality entity) = OBSERVERS agent quality
entity where
observe :: quality entity - agent - IO Observation
express :: quality entity - agent - Value
observe quale agent = do
clockTime - getClockTime
return (Observation (express quale agent)
(getPosition agent) clockTime)
instance OBSERVERS WeatherStation Temperature AmountOfAir where
express (Temperature (AmountOfAir heat moisture)) weatherStation =
Measure heat
{-
-- running the following
express (Temperature (AmountOfAir 40 20)) (WeatherStation rr 6)
-- Gives
Measure 40.0 Measure 40.0
-- We can get the type: Value
:t express (Temperature (AmountOfAir 40 20)) (WeatherStation rr 6)
-}
Tá an teachtaireacht seo scanta ó thaobh ábhar agus víreas ag Seirbhís
Scanta Ríomhphost de chuid Seirbhísí Faisnéise, ITBÁC agus meastar í a
bheith slán. [1]http://www.dit.ie
This message has been scanned for content and viruses by the DIT
Information Services E-Mail Scanning Service, and is believed to be
clean. [2]http://www.dit.ie
References
1. http://www.dit.ie/
2. http://www.dit.ie/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC bug? Let with guards loops
As Dan said, this behaviour is correct.
The confusing thing here is that in case expressions guards are attached
to the patterns (i.e. to the lhs), while in let expressions they are
attached to the rhs.
So, despite the common Just x | x 0 part, your examples mean rather
different things.
Here's the translation of 'loops' according to the Report:
loops =
let Just x =
case () of
() | x 0 - Just 1
in x
Here it's obvious that 'x' is used in the rhs of its own definition.
Roman
* Andreas Abel andreas.a...@ifi.lmu.de [2013-07-09 16:42:00+0200]
Hi, is this a known bug or feature of GHC (7.4.1, 7.6.3)?:
I got a looping behavior in one of my programs and could not explain
why. When I rewrote an irrefutable let with guards to use a case
instead, the loop disappeared. Cut-down:
works = case Just 1 of { Just x | x 0 - x }
loops = let Just x | x 0 = Just 1 in x
works returns 1, loops loops. If x is unused on the rhs, the
non-termination disappears.
works' = let Just x | x 0 = Just 1 in 42
Is this intended by the Haskell semantics or is this a bug? I would
have assumed that non-recursive let and single-branch case are
interchangeable, but apparently, not...
Cheers,
Andreas
--
Andreas AbelDu bist der geliebte Mensch.
Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY
andreas.a...@ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec error message not making any sense
Hi Fredrik, First, do you use the latest parsec version (3.1.3)? If not, can you try the same with 3.1.3? Second, please upload your code to hpaste.org or a similar service and give us the link. It's not much fun to extract code from an html email. Roman * Fredrik Karlsson dargo...@gmail.com [2013-07-08 23:54:17+0200] Dear list, I have a Parsec parser that fails and gives the following error message: *Main parseFromFile textgridfile testFile Left /Users/frkkan96/Documents/src/ume/umecore/testing/testdata/testdata.TextGrid (line 35, column 5): unexpected t expecting intervals [ Now, this is perfectly understandable, but line 35, col 5 in the file being parsed looks like the supplies image - there is no 't' there. Any ideas on what is going on? The parser I am using is: data VariableLine = VariableLine String String deriving Show data TierType = IntervalTier | PointTier deriving Show data Tier = Tier String deriving Show data LabelFile = LabelFile Double Double deriving Show data Label = Label String TierType Double Double String deriving Show haskelldef = makeTokenParser haskellDef textgridfile :: Parser (LabelFile, [[Label]]) textgridfile = do h - header ll - many1 tier return $ (h,ll) header :: Parser LabelFile header = do string headTS1 start - try (float haskelldef) | (fmap fromInteger $ integer haskelldef ) string xmax = end - try (float haskelldef) | (fmap fromInteger $ integer haskelldef ) string tiers? exists \n string size = integer haskelldef string item []: whiteSpace haskelldef return $ LabelFile start end tier :: Parser [Label] tier = do whiteSpace haskelldef string item [ integer haskelldef string ]: whiteSpace haskelldef try (string class = \IntervalTier\) | string class = \TextTier\ whiteSpace haskelldef string name = char '' name - many quotedChar char '' ? quote at end of cell whiteSpace haskelldef string xmin = try (float haskelldef) | (fmap fromInteger $ integer haskelldef ) whiteSpace haskelldef string xmax = try (float haskelldef) | (fmap fromInteger $ integer haskelldef ) string intervals: size = | string points: size = integer haskelldef whiteSpace haskelldef labelList - many1 (interval name) return $ labelList interval :: String - Parser Label interval tierName = do whiteSpace haskelldef string intervals [ integer haskelldef string ]: whiteSpace haskelldef string xmin = start - try (float haskelldef) | (fmap fromInteger $ integer haskelldef ) whiteSpace haskelldef string xmax = end - try (float haskelldef) | (fmap fromInteger $ integer haskelldef ) whiteSpace haskelldef string text = char '' text - many quotedChar char '' ? quote at end of cell return $ Label tierName IntervalTier start end text which fails on the attached input file. I can't see how 't' is found?? What am I doing wrong? /Fredrik -- Life is like a trumpet - if you don't put anything into it, you don't get anything out of it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Catch multiple exceptions using 'Control.Exception'
* Nikita Karetnikov nik...@karetnikov.org [2013-07-06 20:12:58+0400] Here you go: import Control.Exception import Data.Typeable syncExceptions :: SomeException - Maybe SomeException syncExceptions e | Just _ - cast e :: Maybe AsyncException = Nothing | otherwise = Just e Thanks, but it doesn't work as expected: *Main syncExceptions $ toException StackOverflow Just stack overflow It should return 'Nothing' instead: *Main cast $ toException StackOverflow :: Maybe AsyncException Nothing I've received another solution, and it works fine. I also have other questions (see below). Ah yes, fromException is the right function, of course. Sorry for confusion. Could anyone elaborate on the following terms: a closed sum type and an open existential type? What is the meaning of the words open and closed? Is there an open sum type or a closed existential type? Closed means that the set of possible constructors is, well, closed — you have to decide on it when you're defining your type and you can't later add anything to it. Open means the opposite. A classical example of an open type is any type in an OO language with subtyping, such as Java. You can extend the Object type without limitations, without modifying the Object type itself. Exceptions are very similar in this regard — you can add new classes of exceptions without a need to mess with the Control.Exception module, just by defining a couple of methods. For more details you may want to read An Extensible Dynamically-Typed Hierarchy of Exceptions. Also, I thought that a sum type [1] should only have two value constructors: ... [1] http://chris-taylor.github.io/blog/2013/02/10/the-algebra-of-algebraic-data-types/ That's just different terminology. When talking about Haskell, we usually call any algebraic type with multiple constructors a sum type. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Catch multiple exceptions using 'Control.Exception'
* Nikita Karetnikov nik...@karetnikov.org [2013-07-03 15:50:16+0400] Perhaps you can use `catches` [0]? Maybe, but my idea is to replace 'syncExceptions' with a similar function. Otherwise, it'll be necessary to change (at least) all functions that use 'syncExceptions'. I'd like to avoid that. Here you go: import Control.Exception import Data.Typeable syncExceptions :: SomeException - Maybe SomeException syncExceptions e | Just _ - cast e :: Maybe AsyncException = Nothing | otherwise = Just e Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: A possible alternative to dot notation for record access
* Carter Schonwald carter.schonw...@gmail.com [2013-06-30 03:26:22-0400]
Otoh, would there be any ambiguity wrt applying functions to blocks?
eg
f = (+ 1)
h= f {let x = 7 in 3*x},
would that trip up the syntax?
This is not valid Haskell anyway (there's no such thing as applying
functions to blocks). You can write
h = f (let {x = 7} in 3*x)
or
h = f $ let {x = 7} in 3*x
Roman
On Sun, Jun 30, 2013 at 2:59 AM, Judah Jacobson
judah.jacob...@gmail.comwrote:
Hi all,
I had a quick idea about record field syntax as specified in the GSoC
project plan:
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Plan
.
Instead of f.x (to access field x of record f), maybe we could write
f{x} as the record selection. That is, we'd reuse the brace notation
which is already in place for record updates. Unlike dot notation, this is
unambiguous and doesn't conflict with any existing syntax (AFAIK). It
would also generalize to f{x}{y}{z} instead of f.x.y.z.
This proposal would add two new forms of expressions:
f{x} to access field x of data f
({x}) = \f - f{x} as a field access section
Additionally, it seems like record mutation expressions could also have
sections:
({x=2}) = \f - f{x=2}
That actually seems useful by itself, regardless of whether we use dot
notation for field access.
Best,
-Judah
___
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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overloaded record fields
* Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk [2013-06-24 10:47:09+0100] Restricting function composition to have spaces around it will require changing a large amount of existing code if one is willing to use it. I assume this semantics will be triggered only by an extension, so there'd be no need to change existing code. While I personally would like the restriction because I hate seeing people skimp out on whitespace around operators, there are a lot of people with a different opinion than mine and I imagine it'd be a great inconvenience to make them change their code if they want to start using SORF. Well, if they *want* it, it's not unreasonable to require them to *pay* for it (in the form of adjusting their coding style). Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] ANNOUNCE: haskell-names-0.1
* Andrew Cowie and...@operationaldynamics.com [2013-06-21 16:12:55+1000] On Thu, 2013-06-20 at 18:13 +0300, Roman Cheplyaka wrote: Namely, it can do the following: * for a module, compute its interface, i.e. the set of entities exported by the module, together with their original names. * for each name in the module, figure out what it refers to — whether it's bound locally (say, by a where clause) or globally (and then give its origin). Is this a step toward being able to automatically derive an API version number [in the SO version sense of the word; ie, has a change happened requiring a version bump?] Yes, this sounds like a good weekend project for someone interested. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: haskell-names-0.1
I am pleased to announce the first public release of haskell-names, a name resolution library for haskell-src-exts AST. Namely, it can do the following: * for a module, compute its interface, i.e. the set of entities exported by the module, together with their original names. * for each name in the module, figure out what it refers to — whether it's bound locally (say, by a where clause) or globally (and then give its origin). Thanks to haskell-packages, this library is fully integrated with Cabal, so that you can easily generate name interfaces for any Cabalized package. See more details in the README: http://documentup.com/haskell-suite/haskell-names This library is based on the code written by Lennart Augustsson in 2010. Little of that code survived, but nevertheless it's been a great help. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: ConstraintKinds feature suggestion and question about type family peculiarity
* Merijn Verstraaten mer...@inconsistent.nl [2013-06-15 22:05:52+0100] 2) for some reason the type families syntax always requires a full argument list, which I find rather ugly. I would much prefer to use KindSignatures and write type family Restrict :: * - [*] - Constraint, but GHC does not allow this. Is there a specific reason for not allowing this syntax? I believe this is done to simplify (or even enable) type inference. This is similar to the situation with type synonyms. type M1 = Maybe is different from type M2 a = Maybe a in that M1 has kind * - *, while M2 is not a type constructor and doesn't have a kind — but when applied to a type of kind * it expands to a type of kind *. The same with the type families. You can define type families that return e.g. [*] - *, but then you cannot pattern match on the [*] type argument. If you could, that would be equivalent to type-level lambdas, and that would make type inference hard or impossible. Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Testing invasive proposals with Hackager
To make it clear, it's not yet written, although I'll start spending more time on it soon. So far I've been working on the haskell-suite set of libraries that are necessary to implement HasFix. (https://github.com/haskell-suite) Roman * AlanKim Zimmerman alan.z...@gmail.com [2013-06-13 20:45:43+0200] Roman Cheplyaka has written a tool called HasFix for updating source based on new versions of libraries. The presentation on it is here http://ro-che.info/docs/ and the code is at https://github.com/feuerbach/hasfix Perhaps it could be pressed into use for automatic update of historical code? Alan On Thu, Jun 13, 2013 at 6:30 PM, Maksymilian Owsianny maksymilian.owsia...@gmail.com wrote: I was thinking about something similar some time ago, but not just testing but also fixing things automatically. Taking for example Semigroup = Monoid this would break in places where you have instance for Monoid but don't have instance for Semigroup. But if you have instance for Monoid making instance for Semigroup is straightforward: instance Semigroup TypeYouAreFixing where () = copy code from mappend for that type I'm still kind of new to Haskell, so I'm not sure how hard such, TemplateHaskell-like automagic migration tool, would be to make, but I feel like such a tool would be of incredible importance for the community. Because otherwise, without such thing, there are usually two ways a language can evolve: 1. Caring for backwards compatibility, and accumulating mistakes like that over time, and becoming more and more like crap. 2. Making fixes that break everyones code, and because of that being ignored by the industry. I like Haskell because it usually takes the second route, but as community grows it will be less and less the case. With such a tool you could have best of both worlds. Though I assume that somebody already thought of that and come to the conclusion that in general case you cannot make such tool because Gödel is a bastard that breaks everyones toys, or something along this lines. On Thu, Jun 13, 2013 at 12:54 PM, Niklas Hambüchen m...@nh2.me wrote: On 13/06/13 18:36, Vo Minh Thu wrote: For example, here is a run with GHC, no special options and using 4 threads (note that this generally takes a long time, i.e. a few days): My builds finished in 10 hours on an i7. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Platform 2013.2.0.0 64bit.pkg
* Richard A. O'Keefe o...@cs.otago.ac.nz [2013-06-13 17:37:57+1200] Today I cleared out everything, using uninstall-hs and rm -rf ~/.cabal ~/Library/Haskell I downloaded Haskell Platform 2013.2.0.0 64bit.pkg and installed it. I was unsuccessful in installing the packages I wanted using cabal install, which suggested running ghc-pkg check. So I cleared out everything again and reinstalled the HP. In the admin account, ghc-pkg check says Warning: haddock-interfaces: /Library/Haskell/ghc-7.6.3/lib/haskell-platform-2013.2.0.0/ doc/html/haskell-platform.haddock doesn't exist or isn't a file Warning: haddock-html: /Library/Haskell/ghc-7.6.3/lib/haskell-platform-2013.2.0.0/ doc/html doesn't exist or isn't a directory This is harmless (but should be fixed). Do you need help with your original problem? If so, please give us more details. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Remove Enum from Float and Double
Does such thing as a deprecation pragma for an instance exist? What triggers it? Roman * Johan Tibell johan.tib...@gmail.com [2013-06-11 14:18:41-0700] If we truly believe that the instance is dangerous for users (and not merely for people who don't understand floating point arithmetic on computers), then we should add a deprecation pragma to the instance and discourage its use. But what would the deprecation message encourage instead, for users to write an explicit loop that tests against some lower/upper bound? It would have the same problem as enumFromTo. I think the issue here is really that floating point math on computers is hard to think about. On Tue, Jun 11, 2013 at 11:18 AM, harry volderm...@hotmail.com wrote: Johan Tibell johan.tibell@... writes: I don't see much gain. It will break previously working code and the workaround to the breakage will likely be manually reimplementing enumFromTo in each instance. I forgot the main point of my post :-) The primary motivation for removing these instances is that they cause endless confusion for beginners, e.g. http://stackoverflow.com/questions/13203471/the-math-behind-1-0999-in-haskell , http://stackoverflow.com/questions/9810002/floating-point-list-generator, http://stackoverflow.com/questions/7290438/haskell-ranges-and-floats, http://stackoverflow.com/questions/10328435/how-to-solve-floating-point-number-getting-wrong-in-list-haskell , and many more. On the other hand, how much working code is there correctly using there instances? ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Remove Enum from Float and Double
* Johan Tibell johan.tib...@gmail.com [2013-06-11 15:03:10-0700] On Tue, Jun 11, 2013 at 3:00 PM, Roman Cheplyaka r...@ro-che.info wrote: Does such thing as a deprecation pragma for an instance exist? What triggers it? I don't know. We'll need one if we're going to deprecating core instances. Just deleting them is not an option (as it gives users with large code bases no time to migrate). On a second thought, it does seem feasible. The warning would be triggered at the point where the (implicit) class dictionary is used to invoke a polymorphic function. This, however, requires input from the type checker. All previous deprecations have been only name-based, IINM. Roman ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] ANNOUNCE: standalone-haddock-1.0
* Johannes Waldmann waldm...@imn.htwk-leipzig.de [2013-06-08 12:45:17+] Roman Cheplyaka roma at ro-che.info writes: http://feuerbach.github.io/standalone-haddock/ yes, awesome! I took me a while to figure out I need to add --package-db $HOME/.ghc/x86_64-linux-7.6.3/package.conf.d This is strange, it should look there by default. um, where's --hyperlink-source ? It's not implemented yet. Patches are welcome :) Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: standalone-haddock-1.0
* Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk [2013-06-08 16:16:54+0100] On 07/06/13 13:15, Roman Cheplyaka wrote: I am happy to announce the first release of standalone-haddock. http://feuerbach.github.io/standalone-haddock/ standalone-haddock generates standalone haddock Haskell documentation. When you simply run `cabal haddock`, the resulting HTML documentation contains hyperlinks to other packages on your system. As a result, you cannot publish it on the internet (well, you can, but the links will be broken). standalone-haddock takes several packages for which you want to publish documentation. It generates documentation for them with proper links: * links to identifiers inside this package set are relative * links to identifiers from external packages lead to hackage Thus the resulting directory with HTML is relocatable and publishable. **TL;DR**: it just works. See the [haskell-suite][] documentation for an example output. [haskell-suite]: http://haskell-suite.github.io/docs [snip] I could have really used this about 2 days ago. Oh well. Do you have any idea about how well this will work on all of the GHC source? That is, are there any known issues that would prevent it from working or require a special setup? I imagine it would not be trivial, due to GHC's complicated build system. There's also a known issue that preprocessing doesn't happen (e.g. for alex and happy files) — I hope to fix that soon. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: standalone-haddock-1.1
* Roman Cheplyaka r...@ro-che.info [2013-06-08 19:25:12+0300] There's also a known issue that preprocessing doesn't happen (e.g. for alex and happy files) — I hope to fix that soon. I've just released standalone-haddock-1.1 which fixes the above issue and also adds --hyperlink-source (the latter was kindly contributed by Joey Adams). For some reason my uploads don't finish and the hackage index doesn't get updated. You can still download the source tarball from hackage or github. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: standalone-haddock-1.0
I am happy to announce the first release of standalone-haddock. http://feuerbach.github.io/standalone-haddock/ standalone-haddock generates standalone haddock Haskell documentation. When you simply run `cabal haddock`, the resulting HTML documentation contains hyperlinks to other packages on your system. As a result, you cannot publish it on the internet (well, you can, but the links will be broken). standalone-haddock takes several packages for which you want to publish documentation. It generates documentation for them with proper links: * links to identifiers inside this package set are relative * links to identifiers from external packages lead to hackage Thus the resulting directory with HTML is relocatable and publishable. **TL;DR**: it just works. See the [haskell-suite][] documentation for an example output. [haskell-suite]: http://haskell-suite.github.io/docs Usage - Usage: standalone-haddock [--package-db DB-PATH] -o OUTPUT-PATH [PACKAGE-PATH] Available options: -h,--helpShow this help text --package-db DB-PATH Additional package database -o OUTPUT-PATH Directory where html files will be placed `PACKAGE-PATH` is the path to the (unpacked) package — i.e. a directory with a `.cabal` file. For example: standalone-haddock -o doc haskell-names haskell-packages haskell-src-exts hse-cpp cabal/Cabal **NOTE**: dependencies of every package need to be already installed in the system with documentation (even those dependencies that themselves belong to the current package set). If they are installed in a non-standard package database (e.g. if you use sandboxes), use the `--package-db` option. Cabal dependency The program only builds with (unreleased) Cabal 1.17 which you can get from [github](https://github.com/haskell/cabal). I spent some time trying to make it compatible with Cabal 1.16 (see [Cabal-1.16][] branch), but the API seems to have changed too much. If you seriously care about this, feel free to send a patch, but it's really easier just to install Cabal HEAD. [Cabal-1.16]: https://github.com/feuerbach/standalone-haddock/tree/Cabal-1.16 Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question about Newtype op() function arguments.
* David Banas capn.fre...@gmail.com [2013-06-07 07:08:19-0700] Hi All, Referring to the following, which is taken from the *Control.Newtype *documentation page: op :: Newtypehttp://hackage.haskell.org/packages/archive/newtype/0.2/doc/html/Control-Newtype.html#t:Newtype n o = (o - n) - n - oSourcehttp://hackage.haskell.org/packages/archive/newtype/0.2/doc/html/src/Control-Newtype.html#op This function serves two purposes: 1. Giving you the unpack of a newtype without you needing to remember the name. 2. Showing that the first parameter is *completely ignored* on the value level, meaning the only reason you pass in the constructor is to provide type information. Typeclasses sure are neat. As point #2, above, emphasizes, the only purpose for the first argument to the function (i.e. - the constructor (o - n)) is to specify the type of 'n'. However, being a *newtype*, 'n' can have only one constructor. So, why is it necessary to pass in the constructor to this function, when we're already passing in 'n'? Hi David, Note that that argument is in fact not necessary — 'op' without its first argument is exactly 'unpack'. I imagine that 'op' may be useful if you need to disambiguate the instance in an otherwise ambiguous context. One way to do this is, of course, to provide an explicit type signature, but passing a constructor is another, and rather elegant, way to achieve that. I am not a heavy user of the newtype package, so I can't say how often this situation occurs in practice. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?
* Jason Dagit dag...@gmail.com [2013-06-04 21:00:25-0700]
My preferred solution would be to have ghc/ghci automatically run hsc2hs
(support c2hs also?) when necessary. But so long as it's handled
automatically, I wouldn't be particularly bothered by the implementation.
How about having a `ghci` command for cabal? Or does the automatic
requirement really need to be part of ghc to work the way you want?
(BTW, cabal-dev does have a `ghci` command, but I haven't tested to
see if it does the hsc - hs conversion.)
I don't think cabal can provide that. Let's say you're inside a 'cabal
ghci' session. If you modify the hsc file and reload it in ghci, you'd
expect to load the updated version — yet cabal hasn't even been called
since 'cabal ghci', and have had no chance to re-generate the hs file.
To answer the subject question — hsc2hs is not a single preprocessor
available. There are also c2hs and greencard, and maybe something else.
It is (or, at least, was) not clear which one should be generally
preferred. Perhaps by now hsc2hs is a clear winner — I don't know.
Another option is to add a generic preprocessor option to GHC, something
like -pgmX cmd. Then, for hsc2hs one would write something like
{-# OPTIONS_GHC -pgmX hsc2hs #-}
This is a better option, IMO.
Roman
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Typeable typeclass and type-level naturals
* TP paratribulati...@free.fr [2013-06-05 00:37:36+0200]
Roman Cheplyaka wrote:
Try adding
deriving instance Typeable 'Zero
deriving instance Typeable a = Typeable ('Succ a)
to your module.
(I haven't tested it — you might need to tweak it a bit.)
Thanks Roman.
Unfortunately, I already tried that (without the constraint Typeable a =,
what a fool), but it did not work. The error is the same with the
constraint:
Derived typeable instance must be of form (Typeable 'Succ)
In the stand-alone deriving instance for
‛Typeable a = Typeable (Succ a)’
What is the problem?
Oh, it should probably be simply
deriving instance Typeable 'Zero
deriving instance Typeable 'Succ
Roman
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?
* Ivan Lazar Miljenovic ivan.miljeno...@gmail.com [2013-06-05 17:47:40+1000]
On 5 June 2013 17:34, Roman Cheplyaka r...@ro-che.info wrote:
* Jason Dagit dag...@gmail.com [2013-06-04 21:00:25-0700]
My preferred solution would be to have ghc/ghci automatically run hsc2hs
(support c2hs also?) when necessary. But so long as it's handled
automatically, I wouldn't be particularly bothered by the implementation.
How about having a `ghci` command for cabal? Or does the automatic
requirement really need to be part of ghc to work the way you want?
(BTW, cabal-dev does have a `ghci` command, but I haven't tested to
see if it does the hsc - hs conversion.)
I don't think cabal can provide that. Let's say you're inside a 'cabal
ghci' session. If you modify the hsc file and reload it in ghci, you'd
expect to load the updated version — yet cabal hasn't even been called
since 'cabal ghci', and have had no chance to re-generate the hs file.
To answer the subject question — hsc2hs is not a single preprocessor
available. There are also c2hs and greencard, and maybe something else.
It is (or, at least, was) not clear which one should be generally
preferred. Perhaps by now hsc2hs is a clear winner — I don't know.
Another option is to add a generic preprocessor option to GHC, something
like -pgmX cmd. Then, for hsc2hs one would write something like
{-# OPTIONS_GHC -pgmX hsc2hs #-}
Isn't this what -pgmF is
for?http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/options-phases.html#replacing-phases
{-# OPTIONS_GHC -F -pgmF hsc2hs #-}
Indeed! I should've read the whole section.
Problem solved, then?
Roman
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
