Re: idea: tool to suggest adding imports
Hi John, for the Haskell source modification part I've written hsimport[1]. For finding a certain symbol in the moduls of the dependencies of a project, there's the 'findsymbol' command of a more recent hdevtools[2]. There's also vim-hsimport[3] combining the two. Greetings, Daniel [1] https://hackage.haskell.org/package/hsimport [2] https://hackage.haskell.org/package/hdevtools [3] https://github.com/dan-t/vim-hsimport ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] RFC: Native -XCPP Proposal
Hi Wren, Incidentally, if we really want to pursue the get rid of CPP by building it into the GHC distro... In recent years there've been a number of papers on variational lambda-calculi[1] which essentially serve to embed flag-based preprocessor conditionals directly into the language itself. One major benefit of this approach is that the compiler can then typecheck *all* variations of the code, rather than only checking whichever particular variation we happen to be compiling at the time. This is extremely useful for avoiding bitrot in the preprocessor conditionals. ...If we were to try and obviate the dependency on CPP, variational typing seems like a far more solid approach than simply reinventing the preprocessing wheel yet again. (The downside, of course, is making the Haskell spec significantly more complex.) I think even more beneficial than type checking all cases is the easier support for any Haskell tooling operating with the Haskell source if all cases are part of the AST. Greetings, Daniel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Functional dependencies conflict
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
___
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 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? Greetings, Daniel ___ 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 Wed, Apr 01, 2015 at 02:30:49AM -0700, 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 That would be some kind of harsh april 1st joke, if everything compiled at that day gets a bloated data section by putting lots april strings into it. ;) Greetings, Daniel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Hiding module *exports*
Hi Tom, +1 There's a little bit of bikeshedding that needs to happen (e.g. is hiding (Foo (..)) sufficient to hide the type Foo and not just its constructors), but are people +1 on this? I've frequently wanted this behavior. I would be surprised if 'Foo(..)' would mean in this case something different, so yes, the type Foo should be hidden too. Greetings, Daniel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Hiding import behaviour
Hi Erik, But right now, we have a useful property that adding imports and code to a module does not break or change other code in that module. With this extension, that changes. So your biggest concern is about silent breakage of code, that suddenly a different function is used which has the same name and type, but different semantics. In all other cases the compiler would throw an error, because the types wouldn't match. I have the feeling, that the proposal shouldn't be about implicit/explicit imports, but about prefering the function with the fitting type. If there're two functions with the same name and type in scope, then the compiler most likely should always throw an error. The only exception might be, if there's a function locally defined in the module, then this one might be prefered over every imported one with the same name and type. But perhaps even in this case it might be a good idea to throw an error. Greetings, Daniel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dependencies missing when building ghc.
I am with my new Ubuntu Trusty box. I have installed ghc by apt-get. Then I wanted to build ghc from git to upgrade to 7.8.3. If you only want to install a newer ghc version on ubuntu or even multiple ghc versions at once, then I can only recommend the excellent PPA of Herbert Valerio Riedel: https://launchpad.net/~hvr/+archive/ubuntu/ghc Greetings, Daniel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
On Tue, Jul 29, 2014 at 12:02:19PM +0200, Johan Tibell wrote:
What's the rationale to not require
{-# OVERLAPPING Show [Char] #-}
here? Perhaps it's too annoying to have to repeat the types?
This one might be written at the top of the file, so it would be easier
to overlook it, than having it directly at the instance declaration,
which seems to be one of the major points for OVERLAPPING and OVERLAPPABLE.
Greetings,
Daniel
___
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
On Fri, May 30, 2014 at 02:00:38AM -0700, John Meacham wrote: JHC has the feature that Graphics.UI.GTK.Button can live in any of: Graphics/UI/GTK/Button.hs Graphics/UI/GTK.Button.hs Graphics/UI.GTK.Button.hs Graphics.UI.GTK.Button.hs It lets you have deep module hiarchies without deep directory hierarchies and is not terribly surprising as behaviors go. Well, it might not be terribly surprising in itself, but we just have quite complex systems and the not terribly surprising things just accumulate and then it might get surprising somewhere. I really prefer simplicity and explicitly. If a central tool like GHC adds this behaviour, then all other tools are forced to follow. Greetings, Daniel ___ 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
Hi Simon, I don't quite know what I should think about this addition. Currently you can be sure that modules correspond to directories. After this change you can't be sure anymore. I don't navigate source trees that much by 'cd'-ing into single directories, so deep hierarchies don't bother me that much. There're certainly good intentions in the naming schemes of Haskell modules, but sometimes they just feel a bit forced. So for the module name 'Graphics.UI.Gtk' I might just have chosen the name 'Gtk'. If the library itself wants to separate code into several modules, then the module names can get quite bulky. So using module names to origanize the code and to classifiy its meaning might be a bit too much. Well, just some thoughts. Greetings, Daniel ___ 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
On Fri, Apr 25, 2014 at 07:16:03AM -0700, Eric Seidel wrote: An alternative (and I think this has also been proposed before) is to simply drop the Graphics.UI header from the module hierarchy. The main con here is that there's an increased risk of module name-clashes, but GHC already solves this with the PackageImports extension. I think several of the issues might be resolved by just using the package name as the first module name. Greetings, Daniel ___ 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
On Fri, Nov 08, 2013 at 12:01:13AM -0800, Evan Laforge wrote: When I write my own typecheck msgs, I always write Function expected X, but received Y. That's not too far off from expected / actual, though at least it has an explicit subject. That's perfectly fine, because 'Function + expected' is pointing to the compiler side and additionally 'received' is pointing to the user side. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC error message on type mismatch
Hello, I don't know if I'm the only one struggeling with this GHC error message on type mismatches or it's because I'm not a full time Haskeller, or because I'm not a native english speaker. Couldn't match type `A' with `B´ Expected type: B Actual type: A My problem is with 'Expected' and 'Actual', that I'm often unsure if the compiler is expecting something or if I'm the expecting one and the same goes for actual. I know that the compiler is the expecting one and that I'm given the actual thing, but it's quite often that I'm looking at this error and have to repeat this reasoning. It's strange, because normaly I can memorize such things quite good, but this one bothers me. Perhaps it would be easier for myself if 'Actual type' would be called e.g. 'Given type', I don't know, that just one of the two has a less generic meaning. Greetings, Daniel ___ 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
Hi Simon, On Thu, Nov 07, 2013 at 02:02:06PM +, Simon Peyton-Jones wrote: The motivation is this. Consider f True where f :: Int - Char Then f *expects* an argument of type Int but the *actual* argument has type Bool Does that help? If you would switch the meaning of 'Expected' and 'Actual', than it still could make perfectly sense and my brain seems to tend to this switched meaning. I think my main issue is the word 'Actual'. I seem to associate something more authoritative with this word and not just a wrongly given type by the user, and on the other side 'Expected' doesn't feel authoritative enough. Yes, I think the combination of the words 'Expected' and 'Actual' is irritating me and that I'm perceiving 'Actual' as the more authoritative one. 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'. Greetings, Daniel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC API: modInfoIsExportedName, String - Name?
Hi Ranjit, I should have added that you should call them after compiling the particular target (or with the environment obtained after compiling from a particular target) did you do that? I don't compile anything in my context, but I'm just reading the information of already compiled modules/packages. So if I'm using 'lookupRdrNameInModule' instead of 'tcRnLookupRdrName', than I'm getting the desired information, perhaps that's the difference between your and my use case. But now I'm seeing, that my previous profiling was a bit halfhearted and I missed the real hot spot. After adding several cost centres by hand, I'm seeing that getModuleInfo takes up the most time. Does anyone know why that's the case, why getModuleInfo is so costly and if there's an other way to get the exports of a module? Most allocations seem to be done by getModuleInfo, so getModuleInfo seems to create the data structures holding the complete module information. So there's presumably little hope to get this information faster, right? Greetings, Daniel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC API: modInfoIsExportedName, String - Name?
Hi Ranjit, unfortunately both versions don't seem to work. parseName :: GhcMonad m = String - m [Name] This version yields an exception - I can't remember the exact text - but something like symbol not found. hscParseIdentifier :: HscEnv - String - IO (Located RdrName) tcRnLookupRdrName :: HscEnv - RdrName - IO (Messages, Maybe [Name]) By this version the returned names by tcRnLookupRdrName are empty and also the returned messages are empty, or 'printBagOfErrors' doesn't output anything for them. Greetings, Daniel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RTS option -A affecting cpu-core usage?
Hi all, I played around with a parallel algorithm and tried to get the GC time down by specifying the RTS option '-A'. But if I'm specifying '-A' than also the usage of the cpu-cores seems to change. Without '-A' I'm getting a total cpu-core usage of '4.44s', with '-A' I'm getting only '1.67s'. Any ideas? Greetings, Daniel Without '-A': - dan@machine ~ ghc-mod-dev find showWindows +RTS -s -N4 XMonad.Util.XUtils 980,770,296 bytes allocated in the heap 552,122,168 bytes copied during GC 163,683,152 bytes maximum residency (11 sample(s)) 4,369,800 bytes maximum slop 280 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 1690 colls, 1690 par2.45s0.66s 0.0004s0.0024s Gen 111 colls,10 par0.98s0.26s 0.0239s0.1022s Parallel GC work balance: 18.06% (serial 0%, perfect 100%) TASKS: 6 (1 bound, 5 peak workers (5 total), using -N4) SPARKS: 1025 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 1025 fizzled) INITtime0.00s ( 0.00s elapsed) MUT time0.99s ( 0.83s elapsed) GC time3.43s ( 0.93s elapsed) EXITtime0.02s ( 0.02s elapsed) Total time4.44s ( 1.78s elapsed) Alloc rate995,571,064 bytes per MUT second Productivity 22.7% of total user, 56.5% of total elapsed gc_alloc_block_sync: 53552 whitehole_spin: 0 gen[0].sync: 75 gen[1].sync: 23678 With '-A': -- dan@machine ~ ghc-mod-dev find showWindows +RTS -s -N4 -A500m XMonad.Util.XUtils 979,761,872 bytes allocated in the heap 94,043,424 bytes copied during GC 118,609,784 bytes maximum residency (2 sample(s)) 2,844,808 bytes maximum slop 2196 MB total memory in use (0 MB lost due to fragmentati Tot time (elapsed) Avg pause Ma Gen 0 0 colls, 0 par0.00s0.00s 0.s Gen 1 2 colls, 1 par0.47s0.18s 0.0878s Parallel GC work balance: 57.02% (serial 0%, perfect 100%) TASKS: 6 (1 bound, 5 peak workers (5 total), using -N4) SPARKS: 1025 (616 converted, 0 overflowed, 0 dud, 0 GC'd, 409 fizzl INITtime0.02s ( 0.02s elapsed) MUT time1.16s ( 1.16s elapsed) GC time0.47s ( 0.18s elapsed) EXITtime0.02s ( 0.02s elapsed) Total time1.67s ( 1.38s elapsed) Alloc rate844,914,346 bytes per MUT second Productivity 70.8% of total user, 85.9% of total elapsed gc_alloc_block_sync: 33458 whitehole_spin: 0 gen[0].sync: 5372 gen[1].sync: 0 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RTS option -A affecting cpu-core usage?
Ok, I think I got it. The cpu-cores are spending most of their time doing GC, by reducing the GC time the cpu-cores don't have anything left to do. Seems like a really great parallel algorithm ;). Greetings, Daniel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overloaded record fields
Hi Evan, 1 - Add an option to add a 'deriving (Lens)' to record declarations. That makes the record declare lenses instead of functions. Well, no, that's exactly the kind of magic programming language hackery, that Haskell shouldn't be part of. Deriving should only add something, but not change the behaviour of the underived case. I'm really for convenience, but it shouldn't be added willy-nilly, because in the long term this creates more harm. Greetings, Daniel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to start with GHC development?
Hi Jan, On Thu, Dec 13, 2012 at 01:56:13PM +0100, Jan Stolarek wrote: That's what I'm trying to figure out right now. GHC build system looks very complicated and it seems I'll be spending weeks on understanding it before I can get to the compiler code itself. I think it's easier to have a fix point. Look for something you would like to add to GHC, for a bug you would like to fix. Starting at this fix point you can spread out and learn all the necessary things to be able to implement it. Sure, you will never know if you know enough to implement it in the most fitting way for GHC. But I would consider this as part of the learning process and the GHC developers will give you appropriate feedback. I think that it's quite hard to learn such a big system like GHC in a top to bottom manner and for myself it's easier to stay motivated if I've a concrete task, the learning has a concrete reason. Greetings, Daniel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to start with GHC development?
Hi Chris, On Thu, Dec 13, 2012 at 02:52:37PM +, Chris Nicholls wrote: I worked on my own, but the GHC folk were very helpful when I got stuck. That was quite a slow tactic in retrospect, I reckon I could have got much further if I'd had the bottle to ask more questions. One problem with the Haskell community is that everyone else seems so much smarter... Smart people won't think of you to be dumb because you know less, because they know how little they know themself. ;) Fear is such a drawback and the more reserved guys get easily intimidated by the cocky guys, because they think that the cocky guys really know what they're doing. Greetings, Daniel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needs your help
On Thu, Jul 12, 2012 at 03:13:42PM -0400, Cale Gibbard wrote:
There are of course already lots of ways to create functions which
don't involve \
Well, I think it should be clear that we're talking here about
anonymous functions.
We're not exactly talking about function definitions, so much as
expressions whose value happens to be a function. The point is just
that there are already a few other places in the syntax where the
omission of a value results in a function having the omitted value as
its parameter. At least to me, it seems natural to extend that pattern
in this case.
The question is, how self explanatory is the syntax? I think that
sections and partial function application are pretty self explanatory
just by looking at the expression, because it tells you visually pretty
well what it actually does.
'case of {}' isn't self explanatory, because you don't have a visual
hint what happend with the parameter between 'case' and 'of'.
I can see why - I think it was Simon - proposed '\of', because you could
read it as if the parameter between 'case' and 'of' is applied to the 'of'.
I don't like the version 'case of {}' and I even don't like the version
'\case of' that much, because I think both versions degrade the syntax
of Haskell, which is part of the beauty of Haskell and we shouldn't rush
in expanding it, only for pragmatic reasons.
Greetings,
Daniel
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needs your help
On Thu, Jul 12, 2012 at 01:38:56PM -0400, Cale Gibbard wrote: Personally I don't see why everyone appears to prefer the syntax with \ in it over just the obvious case section syntax which was originally proposed. I don't think that the 'case section syntax' is obvious, because I don't see the similarity between a function definition and a partial function application. Always using '\' would be a visual hint for a function definition. Greetings, Daniel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
